In Jenkins I would like to build my test environment based on the "Build Pipeline Number" to make tests and deployment repeatable (on the same source version), but I didn't find any environment variable to retrieve this number. I tried to use the BUILD_ID but it is different for each job (downstream project).
Is it possible to retrieve the Build Pipeline Number? Or is there any other control number that I can use that is the same for all the jobs (increases on a new build)?
If you are using the less popular Delivery pipeline plugin there is a PIPELINE_VERSION environment variable. Otherwise, with the Build pipeline plugin you would probably have to use your VCS revision number and pass it downstream with Parameterized Trigger Plugin
If you would like to see the list of all current available environment variables just run a batch command SET from your build step (or if linux in shell env)
Related
I want to have one Jenkins job control the build number of another job but without the inconvenience of reloading the entire project configuration from disk. I have seen that it's easily possible to directly update the nextBuildNumber file of the target job (I can do this as a build step of Job A) but this does not take effect immediately. Restarting Jenkins or even reloading the Jenkins configs from disk takes way too long and can only be done when there are no builds in progress.
I have tried the groovy script mentioned in the below post by running it from the Manage Jenkins > Script Console. The same post also suggests the script can be saved as a file and run from the CLI. Can it be run from a build step?
I want Job A to determine Job B's next build number and set it so that Job B can run (later in the same day) with the desired build number.
https://stackoverflow.com/a/20077362/4306857
Perhaps I should clarify. I'm not familiar with Groovy so I'm looking at the various build step options like "Execute Windows batch command" which I have a lot of experience with. I can see an "Invoke Gradle script" option so I was wondering if there may be a plugin that can run Groovy scripts perhaps?
The reason this requirement has arisen is that we are compiling a product for two different platforms. We want to compile the codebase almost simultaneously for both platforms with two jobs (A & B) which will both update the JIRA cases included in the builds. We feel it will be less confusing to have both these jobs running with the same build number so that when we talk about a particular issue being addressed in build #75, say, we won't have to qualify that by stating the full job name. If JOB-A build #75 and JOB-B build #75 are both compiled on the same day from the same codebase we can test and compare the results of both builds with far less confusion than if the build numbers go out of sync.
Obviously, in the short term we will use the Set Next Build Number plugin to manually keep the build numbers in step but we want to automate this if possible.
Depends on whether or not you are using Version Number plugin:
[ X ] Create a formatted version number
Build Display Name [ X ] Use the formatted version number for build display name.
Assuming you are NOT, this groovy script will do:
def NextNumber=42
job=Jenkins.instance.getItemByFullName('path/to/jobName')
job.nextBuildNumber = NextNumber
job.save();
You will need groovy plugin for that. Place that in an "Execute system Groovy script" step. Make sure to choose system groovy. That will execute on the master, where the job config and metadata is stored so you have access to the Jenkins internals and data.
I'd suggest you should really be using the above options rather than relying on "keeping both jobs in sync" via a script or manually. You can then pass the label to be used from the first job as a parameter to the second job. That would also require Parameterized Trigger as well as Version Number plugins.
You can even use ${BUILD_DATE_FORMATTED} or ${BUILD_TIMESTAMP}, etc.
Postdate: thinking about the problemspace from a different perspective, that of running 2+ builds on different platforms (simultaneously), there's a plugin for that: Matrix project. You can run it as a freeatyle job on multiple nodes or is excellently described as Matrix building in scripted pipeline. Not sure how that would tie in to JIRA.
We have a small java dev environment which uses gradle, Jenkins, and Git. We use an in-house built Gradle plugin to increment build numbers using a file to store the current number. The build number is baked into each build as part of its version data. The build number file is checked into the git workspace for the project.
We are now adding Jenkins to the environment for CI. Jenkins has its own build number which we can access via env var $BUILD_NUMBER.
The downside to our in-house Gradle build number plugin is that it uses a local file and thus builds by multiple developers do not sync build numbers. If we use Jenkins BUILD_NUMBER than that is completely different sequence than the Gradle build number plugin.
What is the best practice for this type of scenario?
If you state that only builds provided by your CI are valid for future usage it seems that you have to rely on Jenkins BUILD_NUMBER.
If you want Jenkins job BUILD_NUMBER to be started from specific value do the following:
Manage Jenkins -> Script Console
Jenkins.instance.getItemByFullName("YOUR_JOB_NAME").updateNextBuildNumber(YOUR_BUILD_NUMBER)
I have a MsBuild process that start as part of build using TFS Build Services 2013. I need to pass a few parameters to this process (for example the build number). I've done this previously by modifying the build template and added these parameters to the list of parameters sent into MSBuild, something that has worked fine.
I did however found that TFS Build Services writes a number of environment variables for run (build number being one of them) and as I easily can change my MSBuild script I'd rather just use these directly variables instead of modifying the build template.
My question is however how this will work when I have several build agents? Won't they write over each others values in the environment variables? Can I be 100% certain in my MSBuild script that I didn't get the build number of the next build that might have started in parallel?
Each TFS build is done using a specific build number. If you have multiple agents working on a 'parallel' build, they will all use the same build number. Each build agent will be running in their own specific environment and will not have any issue if other agents are running in parallel - the build number for one agent will not 'clobber' another during a build.
I have a Jenkins pipeline view. Say for example the first job is BUILD followed by DEPLOY and TEST job. What I'm trying to achieve here is to have a 'rollback logic' in the test job, meaning when the test job is run and it is successful I want to set current build no as a global environment variable (so that I can potentially access build number from any job) possibly called TESTED_BUILD_NO. But if test fails then I want to trigger DEPLOY job by passing TESTED_BUILD_NO which will deploy last test build.
There is a plugin called promotion builds plugin, it mentions PROMOTION_BUILD_NO variable but when I look at /env-vars.html it is not listed there. I tired looking at api/xml as well but no mention of any promotion variables. Can this logic I mention here be achieved using this plugin? If not how is global environment set and accessed in Jenkins?
Instead of using global variables, you can always use lastStableBuild, which is automatically set by jenkins. In DEPLOY job, use link to lastStableBuild from TEST job, which form is : http://JENKINS_ADDRESS/job/JENKINS_JOB/lastStableBuild/
According to jenkins wiki:
Stable build A build is stable if it was built successfully and no publisher reports it as unstable.
You are best advised to manage global variables from the system management screens:
Manage Jenkins -> Configure System -> Global Properties
Much more reliable compared to setting these externally to Jenkins.
this can be changed using script or via execute shell/batch.
Or you can use simple groovy scrip to change the value based on Previous command/build status.
For my Jenkins job, I have setup an environment parameter which tells my build script which configuration to use. I also have slave nodes running on each of my environments to build and deploy my application.
I have tried used the "Restrict where this project can be run" with the value
buildnode-${ENV}
where ENV is the name of my parameter. This doesn't seem to work as label does not perform substitution.
I have also tried the NodeLabel Plugin, which allows me to define which nodes to run the job from. However, this will create two separate selections:
Is there a way to tie this two together, so when I select QA environment, for example, the slave node for the QA server is choose to run the build?
You can try the following work-around: have two builds - A and B. A will set up the environment, save it into a file, and pass the file as a parameter to build B, along with the name of the node on which to run (the parameters will be passed via Parameterized Trigger plugin). B will read the environment (via EnvInject plugin) and run the build on the node passed as the other parameter (you do need to use NodeLabel plugin).