This plugin allows managing Jenkins jobs orchestration using a dedicated DSL, extracting the flow logic from jobs.
This plugin is designed to handle complex build workflows (aka build pipelines) as a dedicated entity in Jenkins. Without such a plugin, to manage job orchestration the user has to combine parameterized-build, join, downstream-ext and a few more plugins, polluting the job configuration. The build process is then scattered in all those jobs and very complex to maintain. Build Flow enables you to define an upper level Flow item to manage job orchestration and link up rules, using a dedicated DSL. This DSL makes the flow definition very concise and readable.
After installing the plugin, you'll get a new Entry in the job creation wizard to create a Flow. Use the DSL editor to define the flow.
The DSL defines the sequence of jobs to be built :
You can pass parameters to jobs, and get the resulting AbstractBuild when required :
Environment variables from a job can be obtained using the following, which is especially useful for getting things like the checkout revision used by the SCM plugin ('P4_CHANGELIST', 'GIT_REVISION', etc) :
You can also access some pre-defined variables in the DSL :
You may need to run a cleanup job after a job (or set of jobs) whenever they succeeded or not. The guard/rescue structure is designed for this use-case. It works mostly like a try+finally block in Java language :
The flow result will then be the worst of the guarded job(s) result and the rescue ones
You may also want to just ignore result of some job, that are optional for your build flow. You can use ignore block for this purpose :
The flow will not take care of the triggered build status if it's better than the configured result. This allows you to ignore UNSTABLE < FAILURE < ABORTED
You can ask the flow to retry a job a few times until success. This is equivalent to the retry-failed-job plugin :
The flow is strictly sequential, but let you run a set of jobs in parallel and wait for completion. This is equivalent to the join plugin :
compared to join plugin, parallel can be used for more complex workflows where the parallel branches can sequentially chain multiple jobs :
you also can "name" parallel executions, so you can later use reference to extract parameters / status :
and this can be combined with other orchestration keywords :
Other plugins that expose themselves to the build flow can be accessed with extension.'plugin-name'
So the plugin foobar might be accessed like:
Write the extension in your plugin
Write the actual extension
future releases may introduce support for some more features and DSL syntax for advanced job orchestration.
As any Job, the Flow is executed by a trigger, and the Cause is exposed to the flow DSL. If you want to implement a build-pipeline after a commit on your scm, you can configure the flow to be triggered as the first scm-polling job is run, but you can as well use any other trigger (manual trigger, XTrigger plugin, ...) for your flow to integrate in a larger process.
JENKINS-16980 major issue to prevent releasing a 1.0 version : build-flow require RUN-SCRIPT permission as it allows to run arbitrary code on master (so bypassing security). Need to setup some sandboxing / security manager to allow editing the DSL with lower permission. Possibly using groovy sandbox, maybe require a more general purpose SecurityManager. Such a component would be useful for all other groovy-related plugins.
JENKINS-19118 make DSL resumable : implementation will probably have significant impact on DSL execution engine. My current plan is to allow the DSL to be executed multiple times, previously-executed "build()" invocation being No-Op. This assumes groovy scripting in DSL is strictly idempotent.
With those two issues in mind, preferred way to add new keyword to DSL is to define an extension in a dedicated plugin.
Please don't enlarge even more this page comment list, that we hardly can follow. Join jenkins-user mailing list and explain your use-case there
Skip to end of metadata Go to start of metadata