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.
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)
We are in the process of switching from VSoft Continua CI to Jenkins for our build management environment. As we use a slightly modified Gitflow process we would like Jenkins to be able to build from any feature, release or hotfix branch and pull requests, we decided to go for the Jenkins Pipeline.
The version number for builds from the release and hotfix branches are based on the branch name (e.g. release/2.1.0) while builds from any other branch or pull request is based on the date (e.g. September 6th 2018 resolves to 18.9.6). Continua CI provides a auto increment build number across all build configurations that is why we use this build number as the final part of our build number (e.g. 2.1.0.10, 18.9.6.11, 2.1.0.12, ...). This generated version number is passed as parameter to MSBuild using this version number as the file version and assembly version of our .NET binaries.
I'm looking for a similar solution in Jenkins. The Jenkins Pipeline assigns a separate auto increment build number per branch and pull request which might lead to two builds from different branches having the same version. I already tried using global environment variables to store the version and increase the value with every build but it seems that global enviroment variables cannot be set from Pipeline tasks.
Is there a way for a Jenkins Pipeline project to share a build number across all branches/pull requests?
Here are a few ideas:
have it file based: have your stage execute on, say, the master node; pick a file and decide on the format (properties file can be a good start); lock, read, update, write, unlock.
delegate this to an external service (for instance, a service with a
REST endpoint that you use to request an ID).
write a plugin for it.
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)
Consider TFS 2010's ability for a Build Controller to have 1+ build agents. Since builds are a subjective topic to the team/environment, consider an environment where builds are performed on commit/check-in. Each Project Collection will have 10+ Team Projects, but perhaps only 1 or 2 are being committed to in a day.
When should a TFS administrator consider creating a new build agent?
Do multiple agents run in parallel?
When a single agent is defined to a Build Controller, does it run serially?
MSDN states: "if you set up your agents to have specialized capabilities..." . What does this mean? A technology/platform differentiator? How can you setup your agents to have specialized capabilities?
How can 'tagging' build agents be used effectively in an environment where builds are (typically) performed on each check-in.
You use multiple build agents to support multiple build machines (I work currently with a build farm with 3 build machines - and thus 3 build agents - to distribute the load).
You also might want to have multiple build agents to be able to run builds in parallel. This is a nice feature to share resources, but a requirement when you start working with Test/Lab Management features.
With the capabilities: for example you can setup a build agent with version 1 of a 3rd party component, and a second build agent with version 2. With tagging you can specify in the build definition which build agent it will choose from out of the pool of build agents.
We use 2 build agents on the same machine at work, since we only have one build machine.
The first one handles our CI builds, and is tag with CI. The build definition for the CI build is set up to only use agents that have the CI tag.
The second one is for manually queued builds, mostly for the release branch builds.
I specialized the CI build agent, because it was not uncommon when we were preparing a new build for QA to have several developers check into the development branch, which would slowing down being able to release the build to QA.
One of our builds takes 9 minutes. Its nice that you don't have to be in the Queue behind it if you happen to deploy at the wrong time.