.lighthouse/jenkins-xdirectory contains the default CI/CD pipelines for Jenkins X with these files:
triggers.yamlto define the lighthouse TriggerConfig which defines the ChatOps and triggering configuration via a spec field which defines presubmits and postsubmits (i.e. Pull Request and Release triggers).
pullrequest.yamldefines the Pull Request pipeline using a Tekton Task, Pipeline or PipelineRun
release.yamldefines the Release pipeline using a Tekton Tekton Task, Pipeline or PipelineRun
jenkins-x.ymlfiles are no longer used by default in new quickstarts instead we use the above. Note if you have projects using
jenkins-x.ymlfiles they are still supported if you import them into v3 or you can use this tool to migrate them to tekton pipelines
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.
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
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
- customise the
triggerChatOps comments for
- configure the
- add new entries for new pipelines; or pipelines with different
pipeline_run_paramsentries to parameterise existing
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:
lighthouse-webhooks-*pod(s) which take the webhooks from your git provider and convert them into
lighthouse-tekton-controller-*pod(s) which watch for
lighthousejobresources and create the Tekton PipelineRun resources
tekton-controller-*pod(s) watches for Tekton PipelineRun resources and conver them into Kubernetes
Any errors will usually be recorded in the
status field of the resource that has issues (
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.