Customizing the build pipeline

To meet your specific needs, you can customize the way that Konflux builds components. You can customize builds in two ways:

  • Change the parameters of the build pipeline of a component.

  • Extend the pipeline with your own tasks (or delete existing tasks).

For example, you might decide to limit how long Konflux saves the images that it builds for pull requests. You can set a limit by changing the value of the image-expires-after parameter. Or you can ensure that images are compliant with regulations for your industry, by adding a compliance check as a task to the build pipeline.

Procedure

To customize the build pipeline in any way, start by taking the following steps:

  1. In your preferred IDE, navigate to the .tekton directory in the repository of your component.

  2. Open the relevant YAML files:

    1. The file ending in -pull-request.yaml determines how Konflux responds when you open pull requests.

    2. The file ending in -on-push.yaml determines how Konflux responds when you push commits.

Changing parameters

Procedure

  1. In the relevant YAML files, in the .tekton directory, customize the parameters of the build pipeline by changing the pipeline params:

    1. To make sure your changes are not overriden, change params with the paths .spec.params.

    2. You can change the default value of existing parameters. For example, for PRs, you could set a value for image-expires-after, like 2w or 5d, so images built for PRs do not last indefinitely.

    3. You can also add parameters. New parameters must include a name and value.

  2. Commit your changes to the repository of the component.

Extending the build pipeline with your own tasks

Before you extend your build pipeline, be aware that doing so causes builds to fail an Enterprise Contract check, if you are using the EC. To resolve this issue, please reference the next procedure after completing this one.

Procedure

  1. In each .yaml file in the .tekton directory, add a new task under .spec.pipelineSpec.tasks.

    Example task:

      name: example-task
  params:
  - name: example-param
    value: “Example”
  runAfter:
  - build-container #You can be more specific by choosing another task
  taskRef:
    params:
    - name: name
      value: example-task # metadata.name field of the Task
    - name: bundle
      value: quay.io/tekton-bundle-catalog/example-task-bundle:1.0
      # For more details on tekton bundles, refer https://tekton.dev/docs/pipelines/pipelines/#tekton-bundles
    - name: kind
      value: task
    resolver: bundles
  when:
  - input: $(params.skip-checks)    #This references the pipeline parameters
    operator: in
    values:
    - "false"

    An example of a custom task added to the pipeline that sends a slack notification when the Pipelinerun fails:

      name: slack-webhook-notification
  params:
    - name: message
      value: PipelineRun $(context.pipelineRun.name) failed
    - name: secret-name
      value: my-secret # name of secret in the your namespace which contains slack web-hook URL under key specified in 'key-name' parameter below
    - name: key-name
      value: dev-team
  taskRef:
    params:
    - name: bundle
      value: quay.io/redhat-appstudio-tekton-catalog/task-slack-webhook-notification:0.1
    - name: name
      value: slack-webhook-notification
    - name: kind
      value: Task
    resolver: bundles
  when:
    - input: $(tasks.status)
      operator: in
      values: ["Failed"]

  2. Commit your changes to the repository of the component.

  • To use slack-webhook-notification task, you need to create a secret in your namespace with at least one key where the value is the webhook URL. For example, to create a secret for Slack, run oc create secret generic my-secret --from-literal dev-team=https://hooks.slack.com/services/XXX/XXXXXX

  • If you want to define a task directly in this file, rather than using taskRef, you can use taskSpec. Visit the documentation linked in the Additional resources section.

Preventing issues with the Enterprise Contract

If you are using the Enterprise Contract (EC) to verify your builds, then extending your build pipeline causes your builds to fail the EC. Specifically, builds begin to violate the Trusted Tasks rule.

At the time of publication, the easiest solution for this problem we can recommend is to skip the Trusted Tasks check.

Procedure

  1. In the repository for your instance of Konflux, find the version of the EC that your pipeline is using in the following directory: /konflux-ci/enterprise-contract/core.

    1. By default, Konflux uses enterprise-contract-service_appstudio.redhat.com_v1alpha1_enterprisecontractpolicy_default.yaml.

  2. Find this line: exclude: []

  3. Between the brackets, insert the value trusted_task.trusted.

  4. Commit this change to the repository.

Exchanging the build pipeline build task with higher memory limits

The buildah task, which builds components from a Dockerfile, has a memory limit of 4 GB. To build components with memory requirements greater than 4 GB, use the following tasks:

Procedure

To exchange the build task with a memory limit of 6 GB, complete the following steps. For a memory limit of 8 or 10 GB, replace the references to 6 GB with the appropriate values.

  1. Go to the GitHub repo of your component.

  2. In each .yaml file in the .tekton directory, under tasks, locate the task named build-container:

    1. Under .taskRef.params, set name to buildah-6gb.

    2. Under .taskRef.params, set bundle to quay.io/redhat-appstudio-tekton-catalog/task-buildah-6gb:0.1.

Bring your own Quay repository to the build pipeline

By default, all pipelines push the images to a local repository that is set up as a part of installation. Ths registry address is registry-service.kind-registry:5001. It is not mandatory to use this local repo, so if you want to use your own Quay repo to control user permissions, you can do this by following the instructions for configuring a push secret for the build piepline.

Verification

When you commit changes to these .yaml files in your repository, Konflux automatically triggers a new build. Wait for Konflux to complete the new build, then verify your changes have been made by following these steps:

  1. Navigate to Activity > Pipeline runs.

  2. Select the most recent build pipeline run.

  3. In the Details tab, confirm that there are new tasks that you added in the pipeline visualization.

  4. In the Logs tab, confirm the following:

    1. Any new tasks are in the navigation bar.

    2. If you changed a parameter’s value, and that value gets printed, the new value is in the log.

Troubleshooting

If you experience any issues with your customized pipeline, try the following solutions:

  • If you believe that your desired parameter values are not being passed into the pipeline, make sure that your assignment of that value doesn’t get overwritten later in the .yaml file.

  • If your new task is not appearing in the pipeline run, ensure the following:

    • You added it to the correct place in the .yaml files, so that it has the path .spec.params or .pipelineSpec.params.

    • You specified a valid runAfter field, and that the task in that field completed successfully.

  • For problems with both parameters and tasks, make sure you committed your changes to the .tekton directory in the repository that Konflux references for the component.

  • If your build pipeline can no longer successfully run, your best option is to simply rebuild the .tekton directory:

Additional resources