github actions updates and docs

[jayunit100]

This is not a "write a bunch of code" task but it is essential, so please expect to spend 2 to 3 weeks on this if you are a new contributor, and only self assign if you have the time to complete it as it might require coordinating several conversations/asking questions in different forums

Looks like we've got some tech debt around the lifecycle for our github actions .
See #522 ... as an example.

Original thread https://kubernetes.slack.com/archives/C02GA1RSCLR/p1692815992205469 ...

• We want them to run for every PR when a PR happens
• We want them to run before merges happen
• We want them to pass for PRs that dont make breaking changes

Can someone verify this for us and update our README with a guide for how our CI is currently working? As a starting point:

• clone this repo,
• look at the .github actions and understand them (ask question sin the sig-network-kpng slack channel if not sure what things are doing, cc @friedrichwilken or @aroradaman or me
• Go to the sig-testing weekly meeting to get an understanding if wanting to understand how / when github actions are triggered on new PRs (from K8s members? what about from non K8s members? How are the actions triggered differently) ?

/good-first-issue

[k8s-ci-robot]

@jayunit100:
This request has been marked as suitable for new contributors.

Guidelines

Please ensure that the issue body includes answers to the following questions:

• Why are we solving this issue?
• To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
• Does this issue have zero to low barrier of entry?
• How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue command.

In response to this:

Looks like we've got some tech debt around the lifecycle for our github actions https://kubernetes.slack.com/archives/C02GA1RSCLR/p1692815992205469 ...

• We want them to run for every PR when a PR happens
• We want them to run before merges happen
• We want them to pass for PRs that dont make breaking changes

Can someone verify this for us and update our README with a guide for how our CI is currently working? As a starting point:

• clone this repo,
• look at the .github actions and understand them (ask question sin the sig-network-kpng slack channel if not sure what things are doing, cc @friedrichwilken or @aroradaman or me
• Go to the sig-testing weekly meeting to get an understanding if wanting to understand how / when github actions are triggered on new PRs (from K8s members? what about from non K8s members? How are the actions triggered differently) ?

/good-first-issue

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[aroradaman]

Currently, the GitHub actions are only being triggered when PR has approved and lgtm labels.
We would love to have them triggered without any dependency on these two labels.

[FZhg]

Hi @aroradaman, I want to work on this! I have enough time. I have read the thread as well. This is my first time to contribute to k8s! 🐳

[FZhg]

/assign

[FZhg]

Hi @jayunit100, could you give me a reference that how the CI guide should look like? Also, Should I check the Prow documentation for verifying the current behavior of the ok-to-test label?

[aroradaman]

@FZhg

Currently, the GitHub actions are only being triggered when PR has approved and lgtm labels.
We would love to have them triggered without any dependency on these two labels.

[sbueringer]

This CAPI action might be useful https://github.com/kubernetes-sigs/cluster-api/blob/main/.github/workflows/pr-gh-workflow-approve.yaml

[FZhg]

Hi, @aroradaman! I have gone through the gh action files and found out that besides docker-action.yml , these files just runs different scripts in the hack directory.

Should a PR trigger the docker-action as well?