How it works
Source Repositories
Boot automatically sets up any source repositories which exist in the repositories/templates folder as SourceRepository custom resources and uses any associated Scheduler custom resources to regenerate the Prow configuration.
Boot also automatically creates or updates any required webhooks on the git provider for your SourceRepository resources.
If you are using GitOps we hope to automate the population of the repositories/templates folder as you import/create projects. Until then you can manually create a Pull Request on your boot git repository via jx step create pullrequest repositories
Pipeline
The install/upgrade process is defined in a Jenkins X Pipeline in a file called jenkins-x.yml.
Typically you won’t need to edit this file; though if you do see the editing guide.
Configuration
The boot process is configured using Helm style configuration in values.yaml
files.
Though we support a few extensions to Helm.
Parameters file
We define a env/parameters.yaml file which defines all the parameters either checked in or loaded from Vault or a local file system secrets location.
Injecting secrets into the parameters
If you look at the current env/parameters.yaml file you will see some values inlined and others use URIs of the form local:my-cluster-folder/nameofSecret/key
. This currently supports 2 schemes:
vault:
to load from a path + key from Vaultlocal:
to load from a key in a YAML file at~/.jx/localSecrets/$path.yml
This means we can populate all the Parameters we need on startup then refer to them from values.tmpl.yaml
to populate the tree of values to then inject those into Vault.
Populating the parameters.yaml
file
We can then use the new step to populate the parameters.yaml
file in the Pipeline via this command in the env
folder:
jx step create values --name parameters
This uses the parameters.tmpl.schema.json file which powers the UI.
Improvements to values.yaml
Support a tree of values.yaml files
Rather than a huge huge deeply nested values.yaml file we can have a tree of files for each App only include the App specific configuration in each folder. e.g.
env/
values.yaml # top level configuration
prow/
values.yaml # prow specific config
tekton/
values.yaml # tekton specific config
then you can omit the prow:
indentation in the env/prow/values.yaml
file to make the YAML you create/edit smaller and simpler.
It also means longer term we can generate JSON schema files for each env/$app/values.yaml
files so that we can support better editor/IDE integration.
values.tmpl.yaml templates
When using jx step helm apply
we now allow values.tmpl.yaml
files to use Go/Helm templates just like templates/foo.yaml
files support inside Helm charts so that we can generate value/secret strings which can use templating to compose things from smaller secret values (for example, creating a maven settings.xml
file or docker config.json
which includes many user/passwords for different registries).
We can then check in the values.tmpl.yaml
file which does all of this composition and reference the actual secret values via URLs (or template functions) to access vault or local vault files
To do this we use expressions like: {{ .Parameter.pipelineUser.token }}
somewhere in the values.tmpl.yaml
values file. So this is like injecting values into the helm templates; but it happens up front to help generate the values.yaml
files.
Feedback
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.