-
Notifications
You must be signed in to change notification settings - Fork 144
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
.tekton/pull-request: run conditionally #1188
Conversation
Tested the expression in https://playcel.undistro.io/ with variations of the following input # Here is the input data in YAML or JSON format.
event: push
target_branch: gh-readonly-queue/main/
body:
pull_request:
draft: false
files:
all:
- "README.md"
- "renovate.json"
- ".github/workflows/checkton.yaml" |
.tekton/pull-request.yaml
Outdated
@@ -17,7 +17,7 @@ metadata: | |||
) && ( | |||
// Don't run pipeline if only these files changed. Note that 'files.all' is an object | |||
// coming from PaC (list of all changed files) while the second 'all' is a CEL macro. | |||
!files.all.all(x, x.matches(r"^(renovate\.json|.*\.md|\.github/.*)$")) | |||
!files.all.all(x, x.matches(r"^(renovate\.json|.*\.md|\.github/.*|\.tekton/.*)$")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we want to exclude .tekton?
I'd like to see if changes in tekton are valid and will pass testing before merging them
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I'm just testing if the exclusion works (and found out that Red Hat Konflux / build-definitions-pull-request
somehow became a required check, so we'll need to disable that)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
\o/ thanks @arewm for removing the required check, now PRs wil no longer be blocked in cases where the .tekton/pull-request pipeline doesn't need to run
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dropped the temp
commit, ready for review
Also add comments. Signed-off-by: Adam Cmiel <acmiel@redhat.com>
Don't run the pipeline if the only changed files are - *.md - .github/* - renovate.json Signed-off-by: Adam Cmiel <acmiel@redhat.com>
a94b09a
to
75cebe2
Compare
As @arewm found out, making the Konflux pipeline a not-required check means that if you press the There have been many requests for GitHub to make the "required check is skippable" behavior sane (https://github.com/orgs/community/discussions/13690), but until that happens, we can't go with this approach. |
Perhaps this could be an enhancement in Pipelines as Code, mark skipped Pipelines as successful? |
openshift-pipelines/pipelines-as-code#1746 if anyone wants to follow up with comments. |
Nice, thanks for filing that. For our use case, we can probably add something to the pipeline to skip just the e2e-tests task, as that's the main one we really care about. But this does seem like it could be a useful generic PaC feature |
The new Task in `.tekton/tasks/changed-dirs.yaml` produces a list of changed directories for a particular pull request as an array result. Given this result guards can be done, e.g. using CEL expressions to limit when a Task on the Pipeline needs to run. This way we can skip expensive Tasks that are unrelated to the change done in the pull request. Similar to work in konflux-ci#1188 and konflux-ci#524, with the distinction that the PipelineRun is executed, only potentially not in full.
The new Task in `.tekton/tasks/changed-dirs.yaml` produces a list of changed directories for a particular pull request as an array result. Given this result guards can be done, e.g. using CEL expressions to limit when a Task on the Pipeline needs to run. This way we can skip expensive Tasks that are unrelated to the change done in the pull request. Similar to work in konflux-ci#1188 and konflux-ci#524, with the distinction that the PipelineRun is executed, only potentially not in full.
The new Task in `.tekton/tasks/changed-dirs.yaml` produces a list of changed directories for a particular pull request as an array result. Given this result guards can be done, e.g. using CEL expressions to limit when a Task on the Pipeline needs to run. This way we can skip expensive Tasks that are unrelated to the change done in the pull request. Similar to work in konflux-ci#1188 and konflux-ci#524, with the distinction that the PipelineRun is executed, only potentially not in full.
The new Task in `.tekton/tasks/changed-dirs.yaml` produces a list of changed directories for a particular pull request as an array result. Given this result guards can be done, e.g. using CEL expressions to limit when a Task on the Pipeline needs to run. This way we can skip expensive Tasks that are unrelated to the change done in the pull request. Similar to work in konflux-ci#1188 and konflux-ci#524, with the distinction that the PipelineRun is executed, only potentially not in full.
The new Task in `.tekton/tasks/changed-dirs.yaml` produces a list of changed directories for a particular pull request as an array result. Given this result guards can be done, e.g. using CEL expressions to limit when a Task on the Pipeline needs to run. This way we can skip expensive Tasks that are unrelated to the change done in the pull request. Similar to work in konflux-ci#1188 and konflux-ci#524, with the distinction that the PipelineRun is executed, only potentially not in full.
The new Task in `.tekton/tasks/changed-dirs.yaml` produces a list of changed directories for a particular pull request as an array result. Given this result guards can be done, e.g. using CEL expressions to limit when a Task on the Pipeline needs to run. This way we can skip expensive Tasks that are unrelated to the change done in the pull request. Similar to work in konflux-ci#1188 and konflux-ci#524, with the distinction that the PipelineRun is executed, only potentially not in full.
The new Task in `.tekton/tasks/changed-dirs.yaml` produces a list of changed directories for a particular pull request as an array result. Given this result guards can be done, e.g. using CEL expressions to limit when a Task on the Pipeline needs to run. This way we can skip expensive Tasks that are unrelated to the change done in the pull request. Similar to work in konflux-ci#1188 and konflux-ci#524, with the distinction that the PipelineRun is executed, only potentially not in full.
The new Task in `.tekton/tasks/changed-dirs.yaml` produces a list of changed directories for a particular pull request as an array result. Given this result guards can be done, e.g. using CEL expressions to limit when a Task on the Pipeline needs to run. This way we can skip expensive Tasks that are unrelated to the change done in the pull request. Similar to work in konflux-ci#1188 and konflux-ci#524, with the distinction that the PipelineRun is executed, only potentially not in full.
The new Task in `.tekton/tasks/changed-dirs.yaml` produces a list of changed directories for a particular pull request as an array result. Given this result guards can be done, e.g. using CEL expressions to limit when a Task on the Pipeline needs to run. This way we can skip expensive Tasks that are unrelated to the change done in the pull request. Similar to work in konflux-ci#1188 and konflux-ci#524, with the distinction that the PipelineRun is executed, only potentially not in full.
The new Task in `.tekton/tasks/changed-dirs.yaml` produces a list of changed directories for a particular pull request as an array result. Given this result guards can be done, e.g. using CEL expressions to limit when a Task on the Pipeline needs to run. This way we can skip expensive Tasks that are unrelated to the change done in the pull request. Similar to work in konflux-ci#1188 and konflux-ci#524, with the distinction that the PipelineRun is executed, only potentially not in full.
The new Task in `.tekton/tasks/changed-dirs.yaml` produces a list of changed directories for a particular pull request as an array result. Given this result guards can be done, e.g. using CEL expressions to limit when a Task on the Pipeline needs to run. This way we can skip expensive Tasks that are unrelated to the change done in the pull request. Similar to work in konflux-ci#1188 and konflux-ci#524, with the distinction that the PipelineRun is executed, only potentially not in full.
The new Task in `.tekton/tasks/changed-dirs.yaml` produces a list of changed directories for a particular pull request as an array result. Given this result guards can be done, e.g. using CEL expressions to limit when a Task on the Pipeline needs to run. This way we can skip expensive Tasks that are unrelated to the change done in the pull request. Similar to work in konflux-ci#1188 and konflux-ci#524, with the distinction that the PipelineRun is executed, only potentially not in full.
The new Task in `.tekton/tasks/task-switchboard.yaml` produces a list of bindings that evaluate to true for a particular pull request as an array result. Given this result guards can be done, e.g. using when expressions to limit when a Task on the Pipeline needs to run. This way we can skip expensive Tasks that are unrelated to the change done in the pull request. Similar to work in konflux-ci#1188 and konflux-ci#524, with the distinction that the PipelineRun is executed, only potentially not in full.
The new Task in `.tekton/tasks/task-switchboard.yaml` produces a list of bindings that evaluate to true for a particular pull request as an array result. Given this result guards can be done, e.g. using when expressions to limit when a Task on the Pipeline needs to run. This way we can skip expensive Tasks that are unrelated to the change done in the pull request. Similar to work in konflux-ci#1188 and konflux-ci#524, with the distinction that the PipelineRun is executed, only potentially not in full.
The new Task in `.tekton/tasks/task-switchboard.yaml` produces a list of bindings that evaluate to true for a particular pull request as an array result. Given this result guards can be done, e.g. using when expressions to limit when a Task on the Pipeline needs to run. This way we can skip expensive Tasks that are unrelated to the change done in the pull request. Similar to work in konflux-ci#1188 and konflux-ci#524, with the distinction that the PipelineRun is executed, only potentially not in full.
The new Task in `.tekton/tasks/task-switchboard.yaml` produces a list of bindings that evaluate to true for a particular pull request as an array result. Given this result guards can be done, e.g. using when expressions to limit when a Task on the Pipeline needs to run. This way we can skip expensive Tasks that are unrelated to the change done in the pull request. Similar to work in konflux-ci#1188 and konflux-ci#524, with the distinction that the PipelineRun is executed, only potentially not in full.
The new Task in `.tekton/tasks/task-switchboard.yaml` produces a list of bindings that evaluate to true for a particular pull request as an array result. Given this result guards can be done, e.g. using when expressions to limit when a Task on the Pipeline needs to run. This way we can skip expensive Tasks that are unrelated to the change done in the pull request. Similar to work in konflux-ci#1188 and konflux-ci#524, with the distinction that the PipelineRun is executed, only potentially not in full.
The new Task in `.tekton/tasks/task-switchboard.yaml` produces a list of bindings that evaluate to true for a particular pull request as an array result. Given this result guards can be done, e.g. using when expressions to limit when a Task on the Pipeline needs to run. This way we can skip expensive Tasks that are unrelated to the change done in the pull request. Similar to work in konflux-ci#1188 and konflux-ci#524, with the distinction that the PipelineRun is executed, only potentially not in full.
The new Task in `.tekton/tasks/task-switchboard.yaml` produces a list of bindings that evaluate to true for a particular pull request as an array result. Given this result guards can be done, e.g. using when expressions to limit when a Task on the Pipeline needs to run. This way we can skip expensive Tasks that are unrelated to the change done in the pull request. Similar to work in konflux-ci#1188 and konflux-ci#524, with the distinction that the PipelineRun is executed, only potentially not in full.
The new Task in `.tekton/tasks/task-switchboard.yaml` produces a list of bindings that evaluate to true for a particular pull request as an array result. Given this result guards can be done, e.g. using when expressions to limit when a Task on the Pipeline needs to run. This way we can skip expensive Tasks that are unrelated to the change done in the pull request. Similar to work in konflux-ci#1188 and konflux-ci#524, with the distinction that the PipelineRun is executed, only potentially not in full.
The new Task in `.tekton/tasks/task-switchboard.yaml` produces a list of bindings that evaluate to true for a particular pull request as an array result. Given this result guards can be done, e.g. using when expressions to limit when a Task on the Pipeline needs to run. This way we can skip expensive Tasks that are unrelated to the change done in the pull request. Similar to work in konflux-ci#1188 and konflux-ci#524, with the distinction that the PipelineRun is executed, only potentially not in full.
The new Task in `.tekton/tasks/task-switchboard.yaml` produces a list of bindings that evaluate to true for a particular pull request as an array result. Given this result guards can be done, e.g. using when expressions to limit when a Task on the Pipeline needs to run. This way we can skip expensive Tasks that are unrelated to the change done in the pull request. Similar to work in konflux-ci#1188 and konflux-ci#524, with the distinction that the PipelineRun is executed, only potentially not in full.
The new Task in `.tekton/tasks/task-switchboard.yaml` produces a list of bindings that evaluate to true for a particular pull request as an array result. Given this result guards can be done, e.g. using when expressions to limit when a Task on the Pipeline needs to run. This way we can skip expensive Tasks that are unrelated to the change done in the pull request. Similar to work in konflux-ci#1188 and konflux-ci#524, with the distinction that the PipelineRun is executed, only potentially not in full.
The new Task in `.tekton/tasks/task-switchboard.yaml` produces a list of bindings that evaluate to true for a particular pull request as an array result. Given this result guards can be done, e.g. using when expressions to limit when a Task on the Pipeline needs to run. This way we can skip expensive Tasks that are unrelated to the change done in the pull request. Similar to work in #1188 and #524, with the distinction that the PipelineRun is executed, only potentially not in full.
The new Task in `.tekton/tasks/task-switchboard.yaml` produces a list of bindings that evaluate to true for a particular pull request as an array result. Given this result guards can be done, e.g. using when expressions to limit when a Task on the Pipeline needs to run. This way we can skip expensive Tasks that are unrelated to the change done in the pull request. Similar to work in konflux-ci#1188 and konflux-ci#524, with the distinction that the PipelineRun is executed, only potentially not in full.
Don't run the pipeline if the only changed files are
*.md
.github/*
renovate.json
Note that a similar attempt was made in #524, which took the approach of enumerating every file/directory which should trigger the pipeline (maybe
files.all
wasn't available at the time). This PR takes the opposite approach.