-
Notifications
You must be signed in to change notification settings - Fork 164
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
check for updated README.md in CI #183
Conversation
yeah sorry about that, Test should pass as soon as we merge #186. |
bb2dc99
to
65ea2aa
Compare
365fb44
to
5235813
Compare
It's working now (committing and pushing the README to the PR branch). To work on fork PRs, it runs on the |
Yeah something ain't right. There is nothing to approve on my end. Also before it showed 3 checks, now its just back to two. Is that expected? Maybe its bugged and we need to push an empty commit Or we can try actually closing this PR and reopening it again. I will try that |
ah nice the good ol' restart. lmao haha |
Oh, I know what that is. Github doesn't allow workflows to trigger other workflows (to avoid infinite loops), so the commit pushed by Github Actions will not trigger the Lint and Test workflow. This sucks for our use case. One workaround, as you've found, is to use the reopen event to trigger the Lint and Test workflow. |
Okay I will hold-off from merging for now. Maybe we can use this: https://docs.github.com/en/actions/reference/events-that-trigger-workflows#workflow_run And then the configured the Lint / Test Flow to run only for helm chart changes and not for updated readmes. Because that shouldn't matter anyway. I know in GitLab CI you can ignore files. So Something like this on:
push:
paths-ignore:
- 'docs/**'
- README.md
- README.md.gotmpl
- 'tools/**' |
I can drop the part of the PR that generates and commits, returning it to how it was at first, if we don't have a good solution for triggering the tests from a generated commit. |
Signed-off-by: Tom Hayward <[email protected]>
Signed-off-by: Tom Hayward <[email protected]>
Signed-off-by: Tom Hayward <[email protected]>
You don't think simply ignoring these files will not work? |
I don't think filtering by files is related. Github doesn't allow a commit from Github Actions to trigger another workflow, but to get it to show up in the list of PR statuses it has to be triggered by the commit. There might be a workaround for this, but it's not obvious to me and I think the other work on this PR (the makefile and PR test) can be helpful even without the automation. |
Yes but maybe we block the "triggering" in the first place if we simply ignore these files. We should do that anyway! No reason to run the complete pipeline when we simply push docs I really think that should work, there wont be any "infinite-loop-protection" because it CI Test / Lint doesn't run anyway for README.md if we ignore it But I can merge this if you want and we figure that out in a seperate PR |
Okay, I was assuming you wanted the Lint and Test workflow to be required on every PR, since that's how the branch protection is set up now. If you don't mind it not running on these commits, it's already doing that successfully (though accidentally) since Github isn't triggering it. The caveat to only running tests when specific files are modified is that Github branch protection does not have a way to say "only require this status check to pass when specific files are modified", so you would need to remove the Lint and Test status checks from the branch protection settings if you are going to only run it for specific files. Yes, if you don't mind iterative improvements, please merge this now and we'll work on v2 when we have a better idea of what if possible and what we want. |
No Problem :). Thank you for your time and the contribution |
I opened #188 for the "generate readme" work and noted the problems with the draft solution. |
What this PR does:
I noticed that the README.md had not been completely updated for the 0.6.0 release. This PR adds a PR check to make sure it has been updated.
Checklist
CHANGELOG.md
updated - the order of entries should be[CHANGE]
,[FEATURE]
,[ENHANCEMENT]
,[BUGFIX]