I have a Jenkins pipeline which is responsible for about 5 stages (build and several different tests). I'm migrating from Jenkins 1.XX (with no pipelines) to Jenkins 2 and I'd like to replicate my process as closely as possible. The pipeline job I have set up on J2 handles everything exactly the same except it's using a JenkinsFile. The only issue is that the pipeline plugin does not appear to support Promotion of particular builds like you can do with Freestyle Jobs. Has anyone found a way around this?
Seems like Promoted Builds Plugin doesn't support pipelines yet. If you check the issue there is also some good pros and cons about supporting it for pipelines.
Related
We have a project where we have several Jenkins jobs:
One type of jobs that runs delivery (A),
one that does just compilation and unit tests (B)
and
one that runs integration tests, static code analysis et cetera (C).
We run on four Jenkins nodes (master + three slaves), and our jobs are a mix of declarative pipeline jobs and manually clicked in Jenkins-jobs.
We only want to run one integration test build per node at a time. However, we want to run as many deliveries (A) and code quality (B) builds as there are executors.
Until now, the Throttle concurrent builds (https://github.com/jenkinsci/throttle-concurrent-builds-plugin) plugin has satisfied our needs. However, this plugin does not support declarative pipeline builds, nor does it at all seem updated.
The Lockable resources plugin (https://github.com/jenkinsci/lockable-resources-plugin) seems promising, but we haven't found any way to lock the entire build with a resource-name dynamically set. That is, when we start a C build, we want it to lock "resource_{name of server}".
This plugin allows setting an entire-build-lock in the options directive,
× ut we haven't figured out how to evaluate an environment variable there.
Any suggestions would be highly appreciated!
So the workaround on our side was to rewrite the pipeline script from declarative to scripted syntax. Then, the throttle concurrent builds-plugin works as a charm.
When the bug https://issues.jenkins-ci.org/browse/JENKINS-49173 is fixed, the plugin will work with declarative pipelines as well.
what is the difference between buildflow, multijob and pipeline plugin.
If i have jobs need to run on the same node sequentially, which one should i use and why?
I have some parameters that are to be shared by all the jobs. I can do it using multijob and build flow also. which one is preferable?
I am confused.
Use the Pipeline plugin.
From the Build Flow plugin page:
"Deprecated: Users should migrate to https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Plugin"
If you're starting from scratch, the answer is basically the same for the Multijob plugin (prefer the pipeline plugin). The Multijob plugin was created pre-jenkins-2, and the pipeline plugin has implemented much of its functionality. Pipeline is one of the default plugins and is being actively maintained by multiple developers. Here is someone migrating from Multijob to Pipeline in 2016.
Currently, I use the Build Pipeline Plugin to orchestrate the delivery of my code through the different environments:
Build the code and execute unit tests
Manually deploy to the development environment
Automatically execute tests on the development environment
Manually release the software and put the version number to the released version.
Manually deploy to the integration test environment by downloading the artefact from a repository, based on the version put by the release build.
Manually deploy to ...
With Jenkins 2.0 comes the Pipeline plugin. But how do these two plugins relate to each other?
Should I migrate to the latest plugin? The things I seem to miss from the Jenkins 2 Pipeline plugin:
Manually trigger a stage. I can wait for an input, but it does not seem to be so elegant
Restart a stage to retrigger a deployment. This does not seem possible.
Visibility into the parameters that were used to trigger a stage, e.g. the version number of the software that was deployed.
Am I missing the point here? Should the two of them be combined? Or how are you approaching a pipeline like this?
With the current state of Jenkins 2 pipelines you are correct to state all the 'missing features' you listed.
One of the advantages of the Jenkins 2 pipeline plugin is that rather than chaining together a series of jobs as with the Build Pipeline Plugin, your entire pipeline is 1 'job', which makes user administration much easier IMO.
The other advantage of Jenkins 2 pipelines would be 'configuration as code', so you can track changes to your pipeline as you would any other file in version control.
Jenkins 2 pipelines are very much the new 'hotness', and there's many plugins implementing compatability day after day.
Once the new UI becomes production ready, I'd imagine that the old build pipeline plugin will begin to be deprecated.
Also you should be aware that the Build Pipeline plugin is not maintained by the Jenkins or CloudBees teams as far as I know, whereas Jenkins 2 pipelines are.
Would I recommend migrating now? No, I personally still don't consider the Jenkins 2 pipelines mature enough for deployment to production in an organisation. I'd stay to stick with what you know for now while you wait for the Jenkins 2 Pipeline ecosystem to mature.
My reasoning I gave in a blog post a few weeks ago (read more here if you want, but I've extracted out the 'weaknesses' here for you):
There are still plenty of plugins that I and many others will consider 'core to their CI pipeline' missing full or partial support for pipelines.
The lack of 'per-project-configuration' in pipelines for many plugins. e.g. Slack - the current implementation 'assumes' that all Jenkins 2 Pipeline projects should be communicated to the same Slack channel/team - whereas you may want to have multiple Slack teams configured. There are multiple other plugins like this.
At present the documentation of Jenkins 2 Pipelines is very limited, though this is improving.
I am actually implementing the continuous integration pipeline of the company I am working for with the help of Jenkins.
What I have done so far is a bit basic:
Create as many jobs as stages in my pipelines and then Build a pipeline view with the jobs I created before. So far so good but just for the test pipeline I have created.
I mean, this pipeline runs over a project. If I want to apply the same 'pipeline actions' against other project, I have to create again all jobs that are within the pipeline > create the Build a pipeline view and I will have another pipeline.
I am trying to extrapolate this into the Jenkins a code concept so that my pipeline will be formed by groovy code and the only thing left to do would be change the name of the project.
What do you guys think about my approach on building Jenkins pipelines?
Cheers,
Sebastian
I had some jenkins standalone jobs to build, package and deploy. Now I am connecting them and making 'build' job trigger 'package' job , and 'package' job to trigger 'deploy' job and am passing the required parameters between them.I can also see them neatly in pipeline view.
My question is, can this technically be called a pipeline? Or can I call it a pipeline only if I use pipeline plugin and write groovy script?
Thanks
p.s: Please do not devote this question. It is a sincere question for which I am not able to find the right answer. I want to be technically correct.
In Jenkins context, a pipeline is a job that defines a workflow using pipeline DSL (here, based on Groovy). A pipeline aims to define a bunch of steps (e.g. build + package + deploy in your case) in a single place, allows to define a complex workflow (e.g. parallel steps, input step, try/catch instructions) that can be both replayed and versionned (because it can be saved to git). For more information you should read Jenkins official pipeline documentation that explains in details what a pipeline is.
The kind of jobs you are currently using are called freestyle jobs, and even if they do define a "flow" (by chaining jobs together), they cannot be called pipelines jobs.
In short, pipelines are jobs that use pipeline plugin and groovy script syntax to define the whole application lifecycle, and standard Jenkins 1.x jobs are called freestyle jobs.