In Jenkins, if we use Post-Build Trigger to start another build
What are ENVs available to the new build.
I need to identify, parent builds Name, Build Number, Last Successful Artifacts' URL etc.,
In simple words, how to get upstream project info on a downstream project
Is that possible
You can use the Parameterized Trigger Plugin to pass variables from one build to the next. It is used in much the same way as the Post Build Trigger plugin you mentioned you're using already.
It defines some variables that are passed through to the next job, but you are free to define your own in the box provided, e.g:
ARTEFACT_URL=www.example.com/builds/$BUILD_NUMBER #using another variable from this build
SOMETHING=VALUE
UPSTREAM_BUILD_NAME=myProject
UPSTREAM_BUILD_NUMBER=$BUILD_NUMBER
#note that you shouldn't override any properties likely to be set in subsequent builds!
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!
I am using the Parameterized Trigger Plugin on my Jenkins server and I am trying to use a pre-defined parameter used while triggering my downstream build. Unfortunately, I can't get it to work the way I want so I wanted to see if someone could point out what I am doing wrong. Here is my parameterized trigger:
And here is where I try to consume the build parameter in a downstream build:
However, this does not seem to work an the project name shows up as blank when the build gets triggered. Is this doable? Am I doing this right? Any help would be appreciated. Thanks!
There are documented issues of this type of behavior in Jenkins version 2.3
However, the following worked for me:
You need to extend your triggered/downstream jobs (every "Job B") to accept additional parameters. Enable in project B the option "This project is parameterized" and add parameters with the same name as the one passed by the project A.
I've a Jenkins job I want to keep running all the time. When a build is ending, I want to immediately trigger another build. How can I do that?
Thanks, Omer
There are two different job configurations for that:
Build Triggers -> Build after other projects are built
Add a post-build action Build other projects
In both cases, you can enter your own Project, so it'll be triggered again every time a build is completed. You can also specify if this should be done only while the project is stable.
There is however one (probably more) drawback in this approach, which is that it'll create enormous overview pages, where all build triggers are listed:
So i'd recommend to do something else and for example use the Jenkins API to trigger a new build. There are many ways to do that, one simple example is adding a build step Execute shell and do something like:
curl -X POST http://localhost:8080/job/$JOB_NAME/build
If you have configured the Jenkins URL, you could also use $JOB_URL. You can also add post parameters to trigger a parameterized build.
I have a job called "development" and another project called "code analysis". At the moment we have two different jobs and different workspaces, but same code; is there any way we could use the same workspace for multiple jobs?I checked the plugins available in Jenkins but I haven't found any suitable one.
Suppose your "development" Jenkins job workspace is /var/workspace/job1. In the "code analysis" job configuration page, under the tab General click on Advanced... and select the option Use custom workspace and give the same workspace /var/workspace/job1 as of your "development" job.
if you were not able to find Use custom workspace you can located it under your project configure>General>Advanced>Use custom workspace
There is a Jenkins Plugins which enables you to create a shared workplace a setup them on every job which need the files from that given repository.
Use Case:
Similar to what you need, first create two jobs from the same Git Repository, then go to "Manage Jenkins" and you create a Shared Workspace. And point to it, on every job you need to read from that files.
Jenkins Plugin
https://wiki.jenkins-ci.org/display/JENKINS/Shared+workspace+plugin#
PS: You should look into "Known Issues" could be a deal breaker for your needs.
sometimes, on fresh copied job, shared-space url parameter not saving to config on first "save", you should save job twice to be sure.
^^ This one it's still unresolved, I tried and still happens. After some several saves (just to be sure) the job runs perfectly.
I tried the inheritance plugin and whoa! that thing is a sledgehammer when all I have is a tiny nail.
I ended up adding a Post-build Action of "Trigger parameterized build on other projects" with "Build on the same node" and a "Predefined parameter". The downstream job needs to have a parameter of the same name defined (WORKSPACE_PARENT) but you can leave it blank. You then define the downstream job with a custom workspace (under General > Advanced)
I chose a post-build action because the actual success of the build job is independent on the results of the downstream build (for now). If you want to bump the results of the downstream job up to the parent job, you need to add it as a build task, not a post-build action.
It works great for what I need.
Parent's post-build task:
Child's custom workspace:
I have a fairly complicated Jenkins job that builds, unit tests and packages a web application. Depending on the situation, I would like to do different things once this job completes. I have not found a re-usable/maintainable way to do this. Is that really the case or am I missing something?
The options I would like to have once my complicated job completes:
Do nothing
Start my low-risk-change build pipeline:
copies my WAR file to my artifact repository
deploys to production
Start my high-risk-change build pipeline:
copies my WAR file to my artifact repository
deploys to test
run acceptance tests
deploy to production
I have not found an easy way to do this. The simplest, but not very maintainable approach would be to make three separate jobs, each of which kicks off a downstream build. This approach scares me for a few reasons including the fact that changes would have to be made in three places instead of one. In addition, many of the downstream jobs are also nearly identical. The only difference is which downstream jobs they call. The proliferation of jobs seems like it would lead to an un-maintainable mess.
I have looked at using several approaches to keep this as one job, but none have worked so far:
Make the job a multi-configuration project (https://wiki.jenkins-ci.org/display/JENKINS/Building+a+matrix+project). This provides a way to inject the job with a parameter. I have not found a way to make the "build other projects" step respond to a parameter.
Use the Parameterized-Trigger plugin (https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin). This plugin lets you trigger downstream-jobs based on certain triggers. The triggers appear to be too restrictive though. They're all based on the state of the build, not arbitrary variables. I don't see any option provided here that would work for my use case.
Use the Flexible Publish plugin (https://wiki.jenkins-ci.org/display/JENKINS/Flexible+Publish+Plugin). This plugin has the opposite problem as the parameterized-trigger plugin. It has many useful conditions it can check, but it doesn't look like it can start building another project. Its actions are limited to publishing type activities.
Use Flexible Publish + Any Build Step plugin (https://wiki.jenkins-ci.org/display/JENKINS/Any+Build+Step+Plugin). The Any Build Step plugin allows making any build action available to the Flexible Publish plugin. While more actions were made available once this plugin was activated, those actions didn't include "build other projects."
Is there really not an easy way to do this? I'm surprised that I haven't found it and even more surprised that I haven't really seen any one else trying to do this? Am I doing something unusual? Is there something obvious that I am missing?
If I understood it correct you should be able to do this by following these Steps:
First Build Step:
Does the regular work. In your case: building, unit testing and packaging of the web application
Depending on the result let it create a file with a specific name.
This means if you want the low-risk-change to run afterwards create a file low-risk.prop
Second Build Step:
Create a Trigger/call builds on other projects Step from the Parameterized-Trigger
plugin.
Entery the name of your low-risk job into the Projects to build field
Click on: Add Parameter
Choose: Parameters from properties File
Enter low-risk.prop into the Use properties from file Field
Enable Don't trigger if any files are missing
Third Build Step:
Check if a low-risk.prop file exists
Delete the File
Do the same for the high-risk job
Now you should have the following Setup:
if a file called low-risk.prop occurs during the first Build Step the low-risk job will be started
if a file called high-risk.prop occurs during the first Build Step the high-risk job will be started
if there's no .prop File nothing happens
And that's what you wanted to achieve. Isn't it?
Have you looked at the Conditional Build Plugin? (https://wiki.jenkins.io/display/JENKINS/Conditional+BuildStep+Plugin)
I think it can do what you're looking for.
If you want a conditional post-build step, there is a plugin for that:
https://wiki.jenkins-ci.org/display/JENKINS/Post+build+task
It will search the console log for a RegEx you specify, and if found, will execute a custom script. You can configure fairly complex criteria, and you can configure multiple sets of criteria each executing different post build tasks.
It doesn't provide you with the usual "build step" actions, so you've got to write your own script there. You can trigger execution of the same job with different parameters, or another job with some parameters, in standard ways that jenkins supports (for example using curl)
Yet another alternative is Jenkins text finder plugin:
https://wiki.jenkins-ci.org/display/JENKINS/Text-finder+Plugin
This is a post-build step that allows to forcefully mark a build as "unstable" if a RegEx is found in console text (or even some file in workspace). So, in your build steps, depending on your conditions, echo a unique line into console log, and then do a RegEx for that line. You can then use "Trigger parameterized buids" and set the condition as "unstable". This has an added benefit of visually marking the build different (with a yellow ball), however you only have 1 conditional option with this method, and from your OP, looks like you need 2.
Try a combination of these 2 methods:
Do you use Ant for your builds?
If so, it's possible to do conditional building in ant by having a set of environment variables your build scripts can use to conditionally build. In Jenkins, your build will then be building all of the projects, but your actual build will decide whether it builds or just short-circuits.
I think the way to do it is to add an intermediate job that you put in the post-build step and pass to it all the parameters your downstream jobs could possibly need, and then within that job place conditional builds for the real downstream jobs.
The simplest approach I found is to trigger other jobs remotely, so that you can use Conditional Build Plugin or any other plugins to build other jobs conditionally.