Status #

GitHub apps #

When the pipeline finishes, the status will be added in the GitHub Check tabs with a short recap of how long each task of your pipeline took and the output of tkn pr describe.

Log error snippet #

When we detect an error in one of the task of the Pipeline we will show a small snippet of the last 3 lines in the task breakdown.

This will only show the output of the first failed task (due of the limitation of the API not allowing to have many characters).

Pipelines as Code try to avoid leaking secrets by looking into the PipelineRun and replace the secrets values with hidden characters. We do this by fetching every secrets on environment variable attached to any tasks and steps, check if there is any match of those values in the snippet and blindly replace them with a ***** placeholder.

This doesn’t support hiding secrets coming from workspaces and envFrom source.

Annotations (alpha feature) #

If you set error-detection-from-container-logs to true in the pipeline-as-code config map, pipelines-as-code will try to detect the errors from the container logs and add them as annotations on the Pull Request where the error occurred.

We currently support only the simple case where the error looks like makefile or grep output of this format:

filename:line:column: error message

tools like golangci-lint, pylint, yamllint and many others are able to output errors in this format.

As an example you can see how Pipelines as Code pull_request.yaml will pass the right arguments to the binary to output in that format.

You can customize the regexp used to detect the errors with the error-detection-simple-regexp setting. The regexp used named groups to give flexibility on how to specify the matching. The groups needed to match is filename, line and error (column is not used) see the default regexp in the config map.

By default Pipelines as code will only look for the last 50 lines of the container logs. You can increase this value in the error-detection-max-number-of-lines setting or set -1 for an unlimited number of lines. This may increase the memory usage of the watcher.

Webhook #

On webhook when the event is a pull request it will be added as a comment of the pull or merge request.

For push event there is other method to get the status of the pipeline.

Failures #

If a namespace has been matched to a Repository, Pipelines As Code will emit its log messages in the kubernetes events inside the Repository’s namespace.

Repository CRD #

Status of your pipeline execution is stored inside the Repo CustomResource.

% kubectl get repo -n pipelines-as-code-ci
NAME                  URL                                                        NAMESPACE             SUCCEEDED   REASON      STARTTIME   COMPLETIONTIME
pipelines-as-code-ci   https://github.com/openshift-pipelines/pipelines-as-code   pipelines-as-code-ci   True        Succeeded   59m         56m

The last 5 status are stored inside the Repository CR.

Using tkn pac describe, you can easily all the statuses of the Runs attached to your repository and its metadatas.

Notifications #

Notifications are not managed by Pipelines as Code.

If you need to have some other type of notification you can use the finally feature of tekton pipeline .

Here is an example task to send a Slack message on failures or successes: https://github.com/chmouel/tekton-slack-task-status

As a complete example you can have a look into the push pipeline and how Pipelines as Code uses it to send a slack message if there is any failures while generating the artifacts on every push: Pipelines as code push pipeline