Editing

Editing pipelines in Jenkins X

Source layout

If you upgrade your cluster to the latest version stream then you will find if you create a new quickstart that:

Editing pipelines

You can now easily modify any of the Task, Pipeline or PipelineRun resources in any git repository - just look in each folder inside .lighthouse for the YAML files to edit.

e.g. for the default Jenkins X CI/CD pipelines edit either:

You can test out changes to the Pull Request pipeline by submitting changes in a Pull Request. Changes to a release only take place after merging the change to the main branch.

Overriding steps

The default pipelines use the default Jenkins X Catalog and so the details of the steps such as the container image and commands used are often inherited.

You can override steps locally by:

Tools

Linting

You can run the jx pipeline lint command from a clone of your repository.

jx pipeline lint

which will verify that have not made any typos.

You can also view the effective pipeline

IDE support

If you use IntelliJ IDEA or Goland you might find the RedHat’s intellij-tekton plugin useful for editing pipelines with schema validation and completion.

If you use VS Code you may want to try Red Hat’s Tekton Pipelines Extension tekton

Add new tasks/pipelines by hand

You can add new pipelines by hand into a new folder inside .lighthouse at any time.

To setup a trigger so that lighthouse will start your pipeline on a presubmits (i.e. for Pull Requests) or for postsubmits (i.e. releases on main branches) you need to also add a triggers.yaml file which uses the lighthouse trigger config file file format with this spec field.

You could look at the default .lighthouse/jenkins-x directory to see how all this works. The triggers.yaml file then refers to the tekton Task, Pipeline or PipelineRun files via the source: attribute in a presubmits or postsubmits entry.

Changing the triggers

You can modify the .lighthouse/*/triggers.yaml file to modify the presubmits and/or postsubmits entries to do things like:

  • customise the rerun_command or trigger ChatOps comments for presubmits
  • configure the branches patterns for postsubmit triggers
  • add new entries for new pipelines; or pipelines with different pipeline_run_params entries to parameterise existing PipelineRun files differently

Diagnosing problems

If you edit pipelines or lighthouse trigger files and things don’t work there’s a couple of places the errors may show up.

We will hopefully add much better linting/error messages on Pull Requests soon to give you better and faster feedback.

Until then you could look in:

  • the lighthouse-webhooks-* pod(s) which take the webhooks from your git provider and convert them into lighthousejob resources
  • the lighthouse-tekton-controller-* pod(s) which watch for lighthousejob resources and create the Tekton PipelineRun resources
  • the tekton-controller-* pod(s) watches for Tekton PipelineRun resources and conver them into Kubernetes Pod resources

Any errors will usually be recorded in the status field of the resource that has issues (lighthousejob or pipelinerun).