We are in the process of moving our build system over to Jenkins or at least seeing if it is viable. One thing that is currently becoming an issue is our build number or build version. We number our builds and CIs based on the changelist that is polled in source at the time of the build.
So for a CIs we tag it "CI-${CL#}-${branch}" and builds we tag them as "${date}-${CL#}-${branch}" (these are simplified, but gives you an idea what I am doing). Jenkins does its auto increment - 1.2.3. etc.
We are using Pipelines and need to do this during the build. As there are post build/CI things that rely on the build number. I could use a new variable to convey the build version, but when looking at the builds on the different nodes, it would be better to identify the build the way we are used to and have it the same as the build version.
Thanks for any help.
D
As you said you are using pipeline scripting, See How to set build name in Pipeline job? to help do that. And pasting that code also for quick reference.
node {
currentBuild.displayName = "fooName"
currentBuild.description = "fooDescription"
}
See also Set the build name and description from a Jenkins Declarative Pipeline
for more info. Hope this helps.
Related
I have a job to maven build our project, we now have one job per release version. As the number of releases grows, there are too many jobs and very hard to find the one we need.
I wonder if there is a way to launch the same job with different parameters? The problem is one job only has one workspace, so I'm not sure if it's possible?
Thanks.
Use This build is Parameterized option to build the jobs. Using this you can build the same job for different parameters. You will be asked to enter the parameter before building or you can also give a default parameter and you can have multiple parameters.
It is good the archive the artifacts which you need later.
You can also have the option keep build forever, this will keep the builds permanently Ir-respective of the number of builds to keep.
To use above option you should enable Discard old build option.
You can also link your repository directly to Jenkins which will trigger the job whenever a new commit is made to master or a new tag is created.
I have a build that's currently using the old build flow plugin that I'm trying to convert to pipeline.
This build can be massively parallelized (many units of work can run on many different nodes) but we only want to extract the source code once at the beginning, preferably with the Pipeline script from SCM option. I'm at a loss to understand how I can share the source extract (which apparently is on the master) with all of the "downstream" nodes that will be used by the pipeline script.
For build flow we extracted to a well-known location on a shared file system and all of the downstream jobs invoked by the flow were passed (or could derive) that location. That always felt icky & I was hoping that pipeline would have solved this problem but I can't find anything to suggest that it has. What am I missing?
I believe the official recommendation for this is to make bundles of the source and then use "stash" and "unstash" to make them available to deeper steps of your pipeline script.
See https://www.cloudbees.com/blog/parallelism-and-distributed-builds-jenkins
Keep in mind that this doesn't do anything to help with line-endings. If you have builds that span OSs with different line endings you either need to make OS-specific stashes, or just checkout to a safe label in each downstream step.
After further research it seems like the External Workspace Manager Plugin does what I'm looking for.
I’m new to Jenkins and I like some help (reassurance) about how I think I should setup my jobs.
The end goal is fairly simple.
Objective 1: When a developer commits code to a mercurial repo Jenkins pulls the changes, builds the project and runs the unit tests. This happens continuously throughout the day so developers get the earliest possible feedback if they break something.
Objective 2: Nightly, Jenkins pulls the last stable build from above and runs automated UI tests. If those tests pass it publishes the nightly build somewhere.
I have a job configured that achieves objective 1 but I’m struggling with objective 2.
(Not the publishing part, the idea of seeding this job with the last stable build of objective 1).
At the moment, I’m planning to use branches in the HG repo to implement this.
My branches would look something like Main >> Int >> Dev.
The job in objective 1 would work on the tip of the Dev branch.
If the build succeeds and the tests pass it would commit to the Int branch.
The job in objective 2 could then simply work on the tip of the Int branch.
Is this how it’s generally done?
I’ve also been looking at/considering:
- plugins like Promoted Builds and Copy Artifacts
- parameterised builds
- downstream jobs
IMO my objectives are fairly common but I can’t find many examples of this approach online. Perhaps it’s so obvious there was no need but I just wanted to check.
In the past I've stored generated artifacts like this in an artifact repository. You could use something like Nexus or Artifactory for this, but I've also just used a flat file system.
You could put the build artifacts in source control, like you said, but there usually isn't a reason to have version control on compiled builds (you should be able to re-create them based on rev numbers) - they usually just take up a lot of space in your repo.
If your version numbers are incremental in nature your nightly job should be able to pull the latest one fairly easily.
Maybe you can capture the last good revision ID and post it somewhere. Then the nightly build can use that last known good revision. The method to go about doing this can vary but its the concept of using revision ID that I want to communicate here. This would prevent you from having to create a separate branch.
Is it possible to set the build result for a build after that build is complete?
I could not find any plugins that do this already, and I was considering writing my own, but I wanted to see if this was even possible before going down that path.
(I have looked at existing code and how the "Fail The Build" plugin works as an example, but my understanding of the Jenkins code base is not advanced enough to understand what all the possibilities are.)
Use case: we have a build pipeline, and near the end of the pipeline there is a deploy-to-qa step that deploys the artifact to a QA environment. We have automated tests before this step to try to catch any problems with the artifact, but our test coverage is not very high in some areas so bugs could still slip through the cracks. I'd like to have the ability to mark a deploy-to-qa build as FAILED after the fact, to denote that that particular pipeline was invalid and is not a candidate for production release. (Basically the same as this Build Pipeline Plugin issue)
After some more investigation in the code, I believe that this is not possible.
From hudson.model.Run:
public void setResult(Result r) {
// state can change only when we are building
assert state==State.BUILDING;
// snip
...
}
So the build result cannot change except when in "building" state.
I could try to muck with the lastSuccessful and lastStable symlinks (as is done with the delete() function in hudson.model.AbstractBuild), but then those would be reset as soon as Jenkins reloaded the build results from jobs/JOBNAME/builds/.
I have an untested suggestion: Make a parametrized build, where the parameter determines if build will fail or not (for example simple bat / shell script testing the parameter from the environment variable it sets, and doing exit 0 or exit 1). This assumes that build pipelines manually triggered step will ask the parameters, and not use default values.
If it does not support interactive build parameters, then some other way is needed to tell this extra build step wether it should fail or not. Maybe editing upstream build description or display name to indicate failure, and then allowing build pipeline to continue to this extra build step, which probably has to use system groovy script to dig out upstream build description or display name.
I have seen several debates on this topic previously, and the outcome was always that it is theoretically possible to do so, but the codebase is not designed to allow this and it would have to be a very hacky workaround.
It's also been said that this is a bad practice in general, although I don't remember what the argument against it was.
I am facing the same requirement. I haven't found an appropriate plugin, changing the build status is not just a flag but has other impacts on links (eg latest successful build etc). So instead of changing the status of the build I looked for a possibility for qualifying the build. The Promoted Builds Plugin apply flags to build to define e.g. different quality stages. Build promotions can be performed manually or based on e.g. downstream project successful builds. Any successful build can be qualified, based on the promotion additional build and post build actions can be executed, e.g tagging or archiving.
Actually I was able to do it by changing the build.xml manually to <result>FAILURE</result>.
I've then played a little bit with mklink to create some symbolic links and also renamed the lastSuccessfulBuild to lastFailedBuild and it worked. If you are allowed to access the filesystem from within a Jenkins PlugIn, then it is possible to write one.
In case you are fine to delete the current build and start the same build using a version number and setting the next BUILD_NUMBER to the deleted one, then you could use this plugin to tell it to fail instead of succeed:
Fail The Build Plugin
I have a build project that I run from TeamCity, now it takes the build.number from TeamCity.
I want to be able to use the buildnumber task (Ant) which in my understanding when used, is supposed to change the value of build number property and increment it for next time.
But it seems that I still get the build number from TeamCity.
How can I use the build number from <buildnumber file="mybuild.number"/>?
Use the TeamCity Autoincrementer plugin to share an incrementing build number between configurations.
The ANT buildnumber task sets the ANT property build.number.
I don't use team city, but the documentation states that it is also setting the same property.... Might explain your problem :-(
Perhaps someone knows how to switch this team city feature off.
Is there a good reason to switch? The only alternative I can offer ivy buildnumber task. It calculates the next build/release number based on what was previously published to the repository. This may not be suitable in your case. I prefer it because I don't depend on build server settings or need to keep a property file under revision control.
I'm afraid so far there is no way to disable build.number property from TeamCity.
The only possibility I can imagine is not to use TeamCity Ant runner and use Command-line runner instead. But in this case you'll miss many nicities of the bundled Ant runner (like immediate test reporting).
Why would you want to use buildnumber task of the Ant? To keep build number across the builds, you'd have either to commit mybuild.number to version control or to run the build always on the same agent in the same place.