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 artifa
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. Th
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 it
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 how
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 part
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 int
