-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Run golangci-lint as soon as ok-to-test is set #9215
Comments
@CecileRobertMichon @fabriziopandini @killianmuldoon @chrischdi What do you think? |
/triage accepted |
Kudos to @rikatz for sharing the idea!! |
Sounds like a good idea to me for sure. |
That sounds great. And should be safe because gh actions do not run with the config which is on a PR. |
Solution 1 has an issue: When e.g. adding the following to the ...
steps:
- name: Block testing
if: ! contains(github.event.pull_request.labels.*.name, 'ok-to-test')
run: echo "Requires ok-to-test" && exit 1 It would also require the Also wondering how the second one works. Using a gh action/workflow to allow gh actions/workflow. Isn't it the case that the gh-workflow-approve workflow won't run either? |
Good points. What about checking for |
Nope, can't do that. Sounds too easy 😂 I'll give it a try. That should do it! |
Issue with that is: there is a small time window between creating a PR and gh actions which would run 🤔 |
Hm good point. Maybe you can check via https://cs.k8s.io/?q=%27ok-to-test%27&i=nope&files=&excludeFiles=&repos= how it works in other repos (and maybe also check how Prow determines when ok-to-test is needed) |
I suspect it works somehow btw. Otherwise they use a broken action :D Maybe we just have to figure out how (or ask them) |
Jep, the GH action to approve the workflows when |
Sounds like a good option. Thx! |
Hmm - on this PR: #9251 The ok-to-test seemed to work initially to run the golangci-lint. But since the PR was pushed again it does not seem to be working - the workflow needs to be approved again. /reopen |
@killianmuldoon: Reopened this issue. In response to this:
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. |
Yup. It has to be approved after every single push |
Probably have to trigger it in more cases: https://github.com/kubernetes-sigs/cluster-api/blob/main/.github/workflows/pr-gh-workflow-approve.yaml#L3 |
🤔 I'll test that again. |
Tricky to catch the issue but this fixes it: #9259 |
Today we have significant toil for maintainers because they always have to manually approve the golangci-lint action for outside contributors (by clicking on approve in the "checks box").
Goal of this issue is to ensure the action is run automatically as soon as the ok-to-test label is applied.
Proposed solution:
contains(github.event.pull_request.labels.*.name, 'ok-to-test')
Probably needs a bit of trial-and-error on a fork, but I think this should work
For 1.
![image](https://private-user-images.githubusercontent.com/4662360/261021393-7952ff09-0632-4ee3-b84a-bd40bbc5f023.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQ0MDYyMTYsIm5iZiI6MTcyNDQwNTkxNiwicGF0aCI6Ii80NjYyMzYwLzI2MTAyMTM5My03OTUyZmYwOS0wNjMyLTRlZTMtYjg0YS1iZDQwYmJjNWYwMjMucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDgyMyUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA4MjNUMDkzODM2WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9OWQ4MGY5NDNiZmQzZTVlNTQ1OGM0ZmJjZmY3Y2QyY2ZjY2VmZjEyYWQwMTRmMGY1ZTk3OTE1OTI0ODJkZTYxMiZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.j8AUY4zAuR83Kbsuqm6vp7B59NNQvcFgp4ORAy98i4M)
There is potentially another alternative, which is approve workflows automatically if ok-to-test is set: https://github.com/kubernetes-sigs/metrics-server/blob/19802fd979b3c8cdf23297cebe9dc62448e9dc9d/.github/workflows/gh-workflow-approve.yaml#L14. This seems somewhat okay as it only requires actions write permissions. But I think I would prefer the option I mentioned above
The text was updated successfully, but these errors were encountered: