jenkins DSL/workflow script to support a 'fabric8.yml' file in a projects source code which can be used to configure the CI/CD process

[jstrachan]

folks could use a seed Jenkins DSL script to generate builds for all projects found in gogs; but folks may wish to configure things differently on a per project basis.

The fabric8cd.groovy file could be used to contain configuration properties and/or Jenkins DSL (or a pipeline DSL or whatnot).

Some examples could be to:

• define project properties
• disable all CI builds
• only enable certain named builds (e.g. only do the CI build; not the full CD pipeline)
• list the pipelines to use (e.g. ["dev", "itest"] but disable ["staging", "production"])
• define the complete Jenkins Job DSL inside the fabric8cd.groovy file
• provide additional pre-post build steps; so reuse the global defaults and then allow things to occur before or after the other pipelines

The generic Jenkins DSL Groovy script could then clone the source of the project; if the fabric8cd.groovy file is there; invoke it then take the results and use them in the logic to create the jobs for it. If its not there then just invoke the usual build process function.

[jstrachan]

BTW I'm wondering if we should use a YAML file for configuration; then allow folks to write optional groovy files for adding new build configurations by hand.

I figure it'd be nice to have a hawtio UI (maybe a forge CLI command too) to configure the CI / CD pipelines.

e.g. we could maybe have a set of standard templates for CI / CD builds / pipelines; then have a default set we use and allow a project to configure which to enable / disable - together with allowing it to opt in or out of gerrit / taiga et al.

[cmoulliard]

Using a yaml config file like circle ci proposes could be a great way to express the project (https://circleci.com/docs/config-sample) definition to be "deployed" for a CI/CD scenario. Ideally this file should be pre-filled with the values that we already know for a specific setup or combination of containers chosen (gogs + jenkins + nexus, gogs + gerrit + jenkins + ...), plugins selected (for jenkins), webhooks, environment (integration, testing, ...)

[cmoulliard]

We could use one of this YAML Java Parser project & include it with a parent/abstract mojo class to process the YAML project config file & calls the different plugins in charge to configure the CD project

• https://bitbucket.org/asomov/snakeyaml
• https://github.com/EsotericSoftware/yamlbeans

[jstrachan]

BTW we already parse YAML with jackson in fabric8 in the kubernetes-api; we do the same to parse the ~/.config/openshift/config file to discover the token / namespace etc.

I'm thinking the 2 main places we'll parse the YAML is

• when calling mvn fabric8:create-build-config to auto-default more stuff from the YAML if its present (e.g. to enable/disable gerrit or to configure the taiga issue tracker name if present etc)
• when the Jenkins Job DSL runs; use the values to help configure which CI builds or CD pipelines to enable

Its mostly the latter but a few things can be read in the former to help make things a little easier

[jimmidyson]

@jstrachan with the v0.6.1 release of Origin just come out there are some changes we need to be aware of, one being the path of the config file (changes to ~/.kube/config to be consistent with upstream). Release notes at https://github.com/openshift/origin/releases/tag/v0.6.1

[jstrachan]

@jimmidyson ah thanks - raised #4184 to track that one

[jstrachan]

FWIW a fabric8.yml file is now created by default in the new project wizard if some devops options are selected