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 Vault
• local: 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.