Jobs and Prow configuration are generated from templates by the Render Templates tool. Check the Render Templates documentation for details about usage.
The templates
directory has the following structure:
data
, which is the subdirectory with files that describe jobs that the Render Templates tool should generate using job definitions from templates.templates
which is the subdirectory with all template files that supply the definition of Prow jobs used in Kyma.config.yaml
, which is the configuration file that describes configuration and jobs that the Render Templates tool should generate using job definitions from templates.
The template list includes:
generic.tmpl
, which is used to create most of the job definitions.kyma-github-release.yaml
that is used for creating the GitHub release after merging the release branch to themain
branch.prow-config.yaml
that serves to create the main Prow configuration without job definitions.releases.go.tmpl
that contains a set of functions for the release which provide the list of currently supported releases and all supported Kyma release branches.whitesource-periodics.tmpl
, which defines a set of periodic jobs that run a Whitesource scan.
The config.yaml
file has two keys:
global
with a map of values available for all templatestemplates
with a list of files to generate
The .yaml files in data
directory have one key:
templates
with a list of files to generate
The config.yaml
and .yaml files in the data
directory serve as the input files for the Render Templates. The program generates the jobs based on the definition and templates which are specified in the files. These files define the names of the template file and output file, their location, and configuration referred to in values
.
See the example of application-gateway
, in which the generic.taml
template is used to create the component and test-related YAML files using values defined by the kyma_generic_component parameter.
templates:
- from: templates/generic.tmpl
render:
- to: ../prow/jobs/kyma/components/application-gateway/application-gateway-generic.yaml
jobConfigs:
- repoName: "github.com/kyma-project/kyma"
jobs:
- jobConfig:
path: components/application-gateway
args:
- "/home/prow/go/src/github.com/kyma-project/kyma/components/application-gateway"
run_if_changed: "^components/application-gateway/|^common/makefiles/"
release_since: "1.7"
inheritedConfigs:
global:
- "jobConfig_default"
- "image_buildpack-golang"
- "jobConfig_generic_component"
- "jobConfig_generic_component_kyma"
- "extra_refs_test-infra"
preConfigs:
global:
- "jobConfig_presubmit"
postConfigs:
global:
- "jobConfig_postsubmit"
- to: ../prow/jobs/kyma/tests/application-gateway-tests/application-gateway-tests-generic.yaml
localSets:
jobConfig_pre:
labels:
preset-build-pr: "true"
jobConfig_post:
labels:
preset-build-main: "true"
jobConfigs:
- repoName: "github.com/kyma-project/kyma"
jobs:
- jobConfig:
path: tests/application-gateway-tests
args:
- "/home/prow/go/src/github.com/kyma-project/kyma/tests/application-gateway-tests"
run_if_changed: "^tests/application-gateway-tests/|^common/makefiles/"
release_since: "1.7"
inheritedConfigs:
global:
- "jobConfig_default"
- "image_buildpack-golang"
- "jobConfig_generic_component"
- "jobConfig_generic_component_kyma"
- "extra_refs_test-infra"
preConfigs:
global:
- "jobConfig_presubmit"
local:
- "jobConfig_pre"
postConfigs:
global:
- "jobConfig_postsubmit"
local:
- "jobConfig_post"
Component jobs are defined similarly to a regular job, with the exception that the name
field must be empty (because the name is generated by the Render Templates tool), and the path
value must be set.
Component job will generate presubmit and postsubmit jobs for the next release, and by default, it will also generate these jobs for supported releases. The rest of the values is copied from the main jobConfig to the generated ones.
A template receives two objects as input:
Values
which contains all the values specified undervalues
in theconfig.yaml
file.Global
which contains values specified underglobal
in theconfig.yaml
file.
See the description of values used by component job templates:
Name | Required | Description |
---|---|---|
name | No | Name must not be set. It is generated for each job. |
path | Yes | Path in a repository to the component files. |
release_since | No | Specifies the release from which this component version applies. |
release_since | No | Specifies the release till which this component version applies. |
skipReleaseJobs | No | Specifies if the Render Templates tools should omit generating job definitions for currently supported releases. |
All the functions from the sprig
library are available in the templates. It is the same library that is used by Helm, so if you know Helm, you are already familiar with them. Also, a few additional functions are available:
releaseMatches {release} {since} {until}
returns a boolean value indicating whetherrelease
fits in the range. Usenil
to remove one of the bounds. For example,releaseMatches {{ $rel }} '1.2' '1.5'
checks if the release$rel
is not earlier than1.2
and not later than1.5
.matchingReleases {all-releases} {since} {until}
returns a list of releases filtered to only those that fit in the range.