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.
Related
I am using jenkins pipeline and my Jenkinsfile has several stages and jobs. Is there any way to run specific job outside of jenkins pipeline ?
Example: Let's say one of the stage is to do "scp build artifacts to remote location". For some reason this got failed and if at all I want to run rest of the jobs manually out of jenkins pipeline, how can I do that ?
I am least interested to invoke a new build. So can we run remaining jobs after failure outside of jenkins pipeline manually ?
You may be able to do it by writing unit test cases to your Jenkinsfile and test them as a maven project. This may or may not solve your problem without looking at your entire problem but if you can reorganize your logic to achieve 100% test coverage then it is doable. You can find more information about writing test cases of Jenkins pipelines here
I'm trying to set up a scenario where a pull request is created on github that triggers a Jenkins multibranch pipeline, and where that multibranch pipeline uses the Generic Webhook Plugin to extract values from the POST request sent from github to jenkins to be used in the script.
Unfortunately, as described on the Generic Webhook Trigger Plugin wiki:
Note: When configuring from pipeline, that pipeline needs to run once, to apply the plugin trigger config, and after that this plugin will be able to trigger the job. This is how Jenkins works, not something implemented in this plugin. You can avoid this by using Job DSL and have Job DSL create pipeline jobs with the plugin configured in that DSL.
This would be OK using a normal pipeline since it would just be a one off on creation of the Jenkins job. The problem however is that a multibranch pipeline will create a new job whenever a new branch/PR is created, and that means that for each pull request I create on github (which triggers my multibranch pipeline script), I have to then run it twice to get the generic webhook functionality working. Having to resubmit for each PR would be tedious for long-run projects.
It seems to me like there are two possible approaches to solving/improving on this problem. One is to try and play around with DSL Jobs (as suggested by the wiki); but I tried this and couldn't get it to work (it was adding a huge amount of complexity to the set up, so I've abandoned it for now).
The second possible solution is as follows: when a PR is created in github, the Generic Webhook will cause a new job to be created in the multibranch pipeline corresponding to that PR; the first time the multibranch pipeline runs the first build of this newly created job will fail for the reason given in the quote above; but then a solution might involve testing that the first job failed and somehow telling Jenkins to try rebuilding for that job again.
So my question relates to this second approach: how can I most neatly run a rebuild for this multibranch pipeline upon the creation of a PR on github?
Any advice/suggestions would be appreciated!
For triggering multibranch pipline by webhook you can use this plugin:
"Multibranch Scan Webhook Trigger"
https://plugins.jenkins.io/multibranch-scan-webhook-trigger/
Actually that is not true for multibranch pipelines. Just ordinary pipelines needs to run twice.
I updated the docs like:
When configuring from pipeline (not multibranch pipeline)...
Is it possible to create Multi-Branch Pipeline Job by a Job DSL which defines the Job by "Pipeline Script" instead of Jenkinsfile contained by each Git Repository?
We wanna avoid to generate and maintain the same Jenkinsfile (except some parameters) in each of our 100 Git Repositories.
At the moment we are using Pipeline Jobs with Job DSL seeded by a Factory Job, but we are limited at them moment with Multi-Branch Builds (Feature Branches). So we wanna switch to Multi-Branch Pipeline Jobs, but there we are limited in seeding them.
I know we could use a Jenkinsfile (Git Repo of Project) which includes other common Jenkinsfiles from the Jenkins, but that is just a workaround.
Only pipeline jobs can have the pipeline defined inline. Multi-branch jobs can't and JobDSL can't change anything about that.
The probably better alternative is using a shared library. You can configure Jenkins to automatically load this library so that the particular Jenkinsfiles in all the repos only have to call a function out of that.
You can e.g. have a look at a Jenkinsfile of a Jenkins plugin - it only calls a function from the shared library:
buildPlugin()
In your case (as you wrote about "except some parameters"), this function could have some parameters that could differ by the different jobs. The buildPlugin function is implemented here in https://github.com/jenkins-infra/pipeline-library/blob/master/vars/buildPlugin.groovy.
While this would still require you to update all your repos, it is probably the better starting point to introduce pipelines in your organisation.
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
The Jenkins pipeline plugin is awesome.
But is it also possible to aggregate pipelines of (dependent projects) e.g. micro-services?
If you have separate jobs that run pipelines you could just call build [job name] to invoke subsequent pipelines
You can use the way that #ebnius says where you have little pipeline jobs and a parent which is orchestrating the complete workflow and calling the different pipelines.
Or you can use the Shared Library plugin (https://jenkins.io/doc/book/pipeline/shared-libraries/) where you define a step per groovy file for example and you have the entire structure modularized.