There are lots of answers to this and I am not going to pretend I know the
"right" answer for you, but here are a few things you may want to consider
when figuring things out:
* In this "pipeline" of jobs you describe, only the initial build has
access to the source repository - rest use
This is interesting, it's something I've been struggling with while
converting our current system over to the new world (I really like the
stage view!).
We currently have a "pipeline" of freestyle jobs, that pass artifacts down
the line. Build (and test) -> Deploy to stage -> Deploy to prod.
Quick and dirty version of a job lister that takes two parameters "job"
(multibranch job name) and "old_job" (non-mb job name) and produces output
that can be used by Active Choices Parameter to present a list of builds to
select. Value is a | delimited set of values, so you may want to parse
Thanks,
> And then modify the selection of the job run to select from multiple
branches (need to write a Groovy based Parameter selector for that) - and
now you can deploy builds from feature branches for testing BEFORE they are
merged into develop
If there are any examples / code snippets on
I am not sure the stages you are talking about are same as what Jenkins
Pipelines calls stages.
Jenkins, at its core, is a job server. In Pipelines, a stage is a segment
of a job. Stages of a build job would be something like "Build Binaries" or
"Upload Build Artifacts" - something that is
New to Jenkins pipeline.
My process is that developers work off of develop branch (Feature branches
and merges of-course).
At any point in time, a release branch is branched off of develop and then
deployed to a stage environment, Once Accepted/approved, the same release
branch is deployed
