GitOps commands #
Pipelines-as-Code support the concept of GitOps commands
a way to have the
users issue a special command on a comment of a Pull Request or a Pushed Commit
to control Pipelines-as-Code
.
The advantage of using a Gitops command
is to get a journal of all the
execution of your Pipeline directly on your Pull request near your code.
GitOps commands on Pull Requests #
For example when you are on a Pull Request you may want to restart all your
pipelineruns, to do so you can add a comment on your pull request starting with
/retest
and all PipelineRuns attached to that pull request will be restarted :
Example :
Thanks for contributing, This is a much needed bugfix, and we love it ❤️ The
failure is not with your PR but seems to be an infra issue.
/retest
If you have multiple PipelineRun
and you want to target a specific
PipelineRun
you can use the /test
and the specific PipelineRun as a comment
to restart it, example:
roses are red, violets are blue. pipeline are bound to flake by design.
/test <pipelinerun-name>
GitOps commands on pushed commits #
If you want to trigger a GitOps command on a pushed commit, you can include the
GitOps
comments within your commit messages. These comments can be used to
restart either all pipelines or specific ones. Here’s how it works:
For restarting all pipeline runs:
- Use
/retest
or/test
within your commit message.
For restarting a specific pipeline run:
2. Use /retest <pipelinerun-name>
or /test <pipelinerun-name>
within your
commit message. Replace <pipelinerun-name>
with the specific name of the
pipeline run you want to restart.
Note:
When executing GitOps
commands on a commit that exists in multiple branches
within a push request, the branch with the latest commit will be used.
This means:
If a user specifies commands like
/retest
or/test
without any argument in a comment on a branch, the test will automatically be performed on the main branch.Examples :
/retest
/test
/retest <pipelinerun-name>
/test <pipelinerun-name>
If the user includes a branch specification such as
/retest branch:test
or/test branch:test
, the test will be executed on the commit where the comment is located, with the context of the test branch.Examples :
/retest branch:test
/test branch:test
/retest <pipelinerun-name> branch:test
/test <pipelinerun-name> branch:test
To issue a GitOps
comment on a pushed commit you can follow these steps:
- Go to your repository.
- Click on the Commits section.
- Choose one of the individual Commit.
- Click on the line number where you want to add a
GitOps
comment, as shown in the image below:
Please note that this feature is supported for the GitHub provider only.
GitOps commands on non-matching PipelineRun #
The PipelineRun will be restarted regardless of the annotations if the comment
/test <pipelinerun-name>
or /retest <pipelinerun-name>
is used . This let
you have control of PipelineRuns that gets only triggered by a comment on the
pull request.
Accessing the comment triggering the PipelineRun #
When you trigger a PipelineRun via a Gitops Command, the template variable {{ trigger_comment }}
get set to the actual comment that triggered it.
You can then do some action based on for example the comment content with a shell script or others.
There is a restriction with the trigger_comment
variable, we modify it to
replace the newline with a \n
since the multi-line comment can cause a issue
when replaced inside the yaml.
It is up to you to replace it back with newlines, for example with shell scripts
you can use echo -e
to expand the newline back.
Example of a shell script:
echo -e "{{ trigger_comment }}" > /tmp/comment
grep "string" /tmp/comment
Custom GitOps commands #
Using the on-comment annotation on your PipelineRun
you can define custom GitOps commands that
will be triggered by the comments on the pull request.
See the on-comment guide for more detailed information.
Cancelling a PipelineRun #
You can cancel a running PipelineRun by commenting on the PullRequest.
For example if you want to cancel all your PipelinerRuns you can add a comment starting
with /cancel
and all PipelineRun attached to that pull request will be cancelled.
Example :
It seems the infra is down, so cancelling the pipelineruns.
/cancel
If you have multiple PipelineRun
and you want to target a specific
PipelineRun
you can use the /cancel
comment with the PipelineRun name
Example :
roses are red, violets are blue. why to run the pipeline when the infra is down.
/cancel <pipelinerun-name>
On GitHub App the status of the Pipeline will be set to cancelled
.
Cancelling the PipelineRun on push request #
You can cancel a running PipelineRun by commenting on the commit. Here’s how you can do it.
Example :
- Use
/cancel
to cancel all PipeineRuns. - Use
/cancel <pipelinerun-name>
to cancel a specific PipeineRun
Note:
When executing GitOps
comments on a commit that exists in multiple branches
within a push request, the branch with the latest commit will be used.
This means:
If a user specifies commands like
/cancel
without any argument in a comment on a branch, it will automatically target the main branch.Examples :
/cancel
/cancel <pipelinerun-name>
If the user issues a command like
/cancel branch:test
, it will target the commit where the comment was made but use the test branch.Examples :
/cancel branch:test
/cancel <pipelinerun-name> branch:test
In the GitHub App, the status of the Pipeline will be set to cancelled
.
Please note that this feature is supported for the GitHub provider only.
Passing parameters to GitOps commands as argument #
Passing parameters to GitOps commands as argument is a Technology Preview feature only. Technology Preview features are not currently supported and might not be functionally complete. We do not recommend using them in production. These features provide early access to an upcoming Pipelines-as-Code features, enabling you to test functionality and provide feedback during the development process.
When you issue a GitOps command, you can pass arguments to the command to redefine some the standard dynamic variables or the custom parameters
For example you can do:
/test pipelinerun1 key=value
and the custom parameter key
if defined as custom parameter will be defined to value
If the comment does not start with a /
it will not be parsed.
You can only override parameters from the standard or when set as custom parameters, you cannot pass arbitrary parameters that hasn’t been defined previously.
You can pass those key=value
anywhere in your comment and it will be parsed.
There is different format that can get accepted, which let you pass values with space or newlines:
- key=value
- key=“a value”
- key=“another "value" defined”
- key=“another value with newline”