Short: Can I set the name of a Jenkins job created automatically by the Multibranch Pipeline job, to something calculated in the job itself?
Long:
We do a lot of microservices with mostly identical build processes, and we would like to have as little hassle building and testing them as we can.
To that end, I am considering the Jenkins Multibranch Pipeline jobs, where I could just add another project repository and have that new repository built with new jobs being created for new branches that contain Jenkinsfiles. That would also cause the new jobs appear on the build monitor. And here is where the problems start.
I would like to see the name of the project on the build monitor cells, rather than something like my_multibranch_pipeline_t ยป temp_branch_one. However, I couldn't find a way to set the JOB_NAME to anything.
Am I missing something?
I really don't know any way to set the job name from the Jenkinsfile. However we solve the same issue that you describe using seedjobs. These are basically freestyle jobs executing Jenkins' Job DSL, which is able to define as many jobs as you like.
We are using a map of service names, mapped to their Git-urls and iterate over that using Groovy's each.
Related
I have a build job on Bamboo that has parameterized branches. All branches (for e.g. feature branches created by developers at will) have a default set of parameters, and specific branches override some of them. Note that once I set a variable for a given branch to a certain value, every build of that branch takes that value. I'm trying to recreate this in Jenkins, but there doesn't seem to be a way to do so.
I created a multibranch pipeline and defined the parameters in my Jenkinsfile with suitable defaults. However, the only way I can override the parameters for a branch is to click "Build with parameters" and update them. That works for that build, but next build that gets triggered reverts back to using the default values. This seems like such a basic use case that I feel like I must be missing something or misconfigured the project somehow, considering I don't have any experience using Jenkins before trying this. Thanks in advance for your help!
We have Jenkins set up with 7 multibranch pipeline projects, each building off the same git repo, but for different target platforms. Each of these multibranch pipelines builds a number of branches. We currently set which branches each multibranch pipeline builds by using the following property in the multibranch project configuration:
Branch Sources -> Git -> Behaviors -> Filter by name (with wildcards)
Currently, each multibranch pipeline has the same string of branches in this Filter by name (with wildcards) field. Each time we want Jenkins to start building a new branch, we go through all 7 multibranch project configurations and update this field to include the new branch.
It's a bit of a pain to go through each configuration and change this field every time, since we always want each configuration to have the same list of branches. Is it possible to simply use some type of a variable in this field? This way we only would need to change one location instead of trying to keep 7 different configurations in sync with each other, which is prone to error and also a bit of a pain.
Thanks for your help!
Allen
Rather than filtering with wildcards, you could try filtering branches with regular expression. In our case, pattern like:
(master|develop|release.*|feature.*|bugfix.*)
has been working well to cover the repository. That is, assuming that you follow Git Flow or similar methodology. Unfortunately, there is no simple way to sync the configuration between MultiBranch Pipelines build from one repository. Neither Multibranch Pipeline, nor Organization plugins are designed to work with Multiple Jenkinsfiles.
Also, you can try to sync only the branch configuration between Projects using Jenkins script console. Most of the Job configuration does not have to be set on Project level. For instance, you can create shared script (or shared library) to would be sourced by other jobs, to set the same job properties on each of them. See How do you load a groovy file and execute it for details.
if you want to use the wildcard you can provide like below:
In this example it will discover only qa and dev branch.
NOTE: You have to use "Discover branches" also with "filter by name (with wildcards)" behaviour.
I am using this plugin: https://developer.ibm.com/urbancode/docs/integrating-jenkins-ibm-urbancode-deploy/
Is there a way to push to multiple components in UCD from inside one Jenkins job? e.g. The same Jenkins project compiles Java and produce three components: app1_web, app1_ear, app1_db in UCD. I see the plugin inside the Post Build Action can only be inserted once in the same job. Guess this is a question in Jenkins.
If you use Pipeline rather than the old Freestyle job type, you can use post-build actions multiple times.
Though I don't know which plugin you're using, and whether it supports Pipeline.
When I create a plain pipeline project I have the option to periodically poll the scm and if changes are detected, the build is run. that worked well for me.
Now I created a multibranch pipeline and added 2 branches. However, in the configuration I can not set the same as in the normal pipeline project, because it tells me I can only view the configurations of the sub-branch-projects.
Maybe I'm also doing it wrong, so I try to tell you what I actually want to achieve.
I have a PHP project inside of a Git repository. There are two branches that I want to be built on new commits (when pushed to the main repository)
The main repository resides on a self hosted version of Bitbucket Server. If possible, I want to avoid hooks and let Jenkins poll for changes on the bitbucket server. So how can I achieve that?
You just need to check the option Periodically if not otherwise run trigger at the multibranch level. This replaces per-job polling, because it also detects new branches and the like.
If I got you right, all you want to do is to build ONLY these 2 branches?
If so, under "Branch Sources" just click the "Advanced" and fill in the textfield "Include branches" your branches e.g. test test2 (note the space between the branch names)
Actually you'll have configure SCM pollig (the way you expect it) in the Jenkinsfile itself. It's the properties DSL elelement that handles the configuration:
properties([
pipelineTriggers([pollSCM('H 20 * * 1-5')])
])
Anyways I highly suggest to have a closer look at the Pipeline Snippet Generator:
<your-jenkins-url>/pipeline-syntax/
it s easy to miss but extremely helpful and it s populated based on your currently installed plugins. There you will also find a comprehensible set of options available for properties
Is there are a way one can share variables across jenkins jobs ?
Job1 collects the required source code and labels them using perl scripts.
Then a number of other jobs compiles the code since there are many versions. As of now i have made the other jobs depend on Job1 so that same code could be collected from head since it was labelled just before in Job1, but this was not the case during release since codes were going in the repository at odd hours so we had no control, so we thought it would be nice if we could find a way to sync the code using perforce label created in Job1. I did not find any way to sync to particular label that got created in a different job.
So i thought if we could set an environment variable and then use the same for the following jobs, then the codes can be in perfect sync. But seems like environment variables cannot be shared across jobs.
I would appreciate any ideas and help.
Can you use the "Use Upstream Project revision" option? It allows you to sync to the changeset of another project.
If you want to stick to the label idea, I think it's doable. I haven't tried this, but I think I would first have the first job create a new label based on the job name and the build number; both are available in the create label post-build action.
If you launch the downstream job using the paramaterized trigger plugin it will have access to the upstream job name and build number as environment variables. The 'P4 Label' field in the downstream job can then use parameter substitution to specify the correct label name to sync to.
Perforce plugin can help you.
Look at section "Sync multiple builds to the same changeset".