ci: skip running builds and tests if no code changed
Changes
Skip running builds and tests on pull requests if the pull request only changes documentation. From what I can tell, there are no e2e tests in use right now triggered by the Tekton Integration workflow which analyze the markdown docs files except the codegen test which checks to ensure the Pipeline api file was updated, however that should only be updated if the pipelines api is changed in the code. The tests themselves take some time. Also, while the Workflows may be free for compute since they're on GHA, they are still unnecessary and if the e2e tests use any ancillary services which have cost (maybe caching, coverage, image hosting, etc) unnecessary runs at least have the potential of incurring cost.
Submitter Checklist
As the author of this PR, please check off the items in this checklist:
- [ ] Has Docs if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps
- [ ] Has Tests included if any functionality added or changed
- [ ] pre-commit Passed
- [ ] Follows the commit message standard
- [ ] Meets the Tekton contributor standards (including functionality, content, code)
- [ ] Has a kind label. You can add one by adding a comment on this PR that contains
/kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep - [ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of good release notes.
- [ ] Release notes contains the string "action required" if the change requires additional action from users switching to the new release
Release Notes
NONE
/kind misc
Note that the tests will still run on this PR since Github Actions only applies the rules from workflows as defined in the target branch.
Yeah if there are docs CI tests we can use a separate filter. Do you know where the docs tests are found or called? I didn't see any inside this file, and outside of verify-codegen it looked like all the tests were unit tests
/approve /cc @AlanGreene @afrittoli
@vdemeester: GitHub didn't allow me to request PR reviews from the following users: AlanGreene.
Note that only tektoncd members and repo collaborators can review this PR, and authors cannot review their own PRs.
In response to this:
/approve /cc @AlanGreene @afrittoli
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.
Hi @aThorp96, let me know if you have any updates on this one. This is a simple one so was hoping to get it merged soon.
@aThorp96 needs a rebase 👼🏼
We can carry this if need be.
I think this will block PRs since the jobs are still required. There's an open GitHub enhancement request related to this: https://github.com/orgs/community/discussions/44490
The common approach is to skip the jobs using if instead, although it requires additional configuration to get the changed files.
Update: GitHub recommended approach: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/troubleshooting-required-status-checks#handling-skipped-but-required-checks
[!WARNING]
If a workflow is skipped due to path filtering, branch filtering or a commit message, then checks associated with that workflow will remain in a "Pending" state. A pull request that requires those checks to be successful will be blocked from merging.
If, however, a job within a workflow is skipped due to a conditional, it will report its status as "Success". For more information, see Using conditions to control job execution.
When a job fails, any jobs that depend on the failed job are skipped and do not report a failure. A pull request that requires the check may not be blocked. To use a required check on a job that depends on other jobs, use the always() conditional expression in addition to needs, see Using jobs in a workflow.
The following Tekton test failed:
| Test name | Commit | Details | Required | Rerun command |
|---|---|---|---|---|
| pull-tekton-pipeline-go-coverage-df | f646f2b5274b60d227c1044882a38877876abc6f | link | true | /test pull-tekton-pipeline-go-coverage-df |
@aThorp96 can you take @AlanGreene's comment into account ?
@AlanGreene Thanks for catching that. This should be trivial to do with an external action like dorny/paths-filter. I could write a step to do this with shell as well if we don't want to add an external action dependency. Any preference?
@AlanGreene Thanks for catching that. This should be trivial to do with an external action like dorny/paths-filter. I could write a step to do this with shell as well if we don't want to add an external action dependency. Any preference?
I don't mind the external dependency, however the last commit on https://github.com/dorny/paths-filter was last year, which could be a red flag. Even if the action is in "problem solved" state, it should feature Dependabot updates or so. New PRs seem to have been ignored. Is there any other alternative?
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: vdemeester, waveywaves
The full list of commands accepted by this bot can be found here.
The pull request process is described here
- ~~OWNERS~~ [vdemeester,waveywaves]
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
Not ready to merge yet. Since I modified non-docs files (esp since I modified the build CI) it should have triggered a build.
Ah it should have run a yamllint, but nothing more I guess, isn't it ? you changed the CI but to skip the CI.. Ah right, we should not skip a build if only the workflow are modified though, indeed.
/hold
@vdemeester @afrittoli This appears to be working as expected now.
/retest
/retest
/retest
/retest
/hold cancel