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.
Related
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.
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.
This seems simple enough, but I can't find a solution for this online.
I am integrating SonarQube into our build definitions that get triggered on check in. I want the version SonarQube uses to be tied back to the project number defined by the business side of things.
Ideally, I would like to be able to prompt the user for input. When you go to check in and it kicks off the build, it would ask you for the project number to be used as the version for SonarQube. Is this something TFS 2015 supports?
User input for build definitions
As far as I know, build definitions that are not manually triggered do not prompt for user input. A prompt allowing users to set build variables is shown for manually triggered builds from the VSTS web page.
SonarQube project version
I would recommend against you using the build or assembly version in your build tasks. This is because the SonarQube concept of version is quite different from the build concept. SonarQube uses versions as a baselining mechanism / to determine the leak period. If you up the version number often, the leak period is going to be too short to be actionable.
I'd recommend keeping the SonarQube project version in sync with your release schedule instead.
The short answer to this question is no, there is no way to prompt for input on a non-manually triggered CI build.
Here's what we did to work around this:
I wrote a Powershell script to read a config file and set the values to environment variables exposed to later build steps. Those variables are then what are specified in the Sonar Begin Analysis build task. I packaged that script up as a custom build task that will read a "sonar.config" file. This means all we have to do is add a "sonar.config" file to each solution we want to run Sonar analysis for, defining the key, name and version for the project, and then this build task will populate all necessary environment variables as the first step in the build.
So not a perfect solution, but it gets the job done without us having to add a lot of extra code to our solutions.
We are using TeamCity 9.x as are main CI server. I'm looking for ways to run a script (PowerShell, Python, ...) when a build is tagged. Is this possible?
The only thing I can think of is to write a simple service which polls the REST API for the last x builds and reads the <tag/> information.
We are using TFS for source control, so labeling the sources is not an option (because a label is unique in TFS).
Are there any other (simpler) ways to do this? Or is there any other way to define build quality and execute something?
Yes you can
In the build trigger definition, you can mention specific subset of tags(using regex patterns) on which teamcity targets are trigeered. In your case, you have to set the triggers to run on tags only
I know this doesn't answer your question but figured I'd mention it anyways since you have TFS in your environment already.
If you were using TFS Build it has a drop down on each build to indicate quality. And there's a free tool called TFS Deployer that allows you to run scripts when the quality is changed.
I'm trying to tweak some options in my jenkins configuration, which is causing many builds to fail. I'd prefer to not keep these failures around in the build history, since they're not technically failures of the repository. In the past, I've just deleted the build after looking at the log, but this is a little tedious.
Is there a way to start a build with an option to not record the result of the build permanently?
Perhaps there's a URL that can be used to trigger a debugging build, somethign like:
JENKINS_URL/job/JOBNAME/build?DEBUGGING
You can set the "discard old builds" option in your job to only keep 1 build. If you have older builds you want to keep, you can give them the "keep this build forever" property. If you have a large number of jobs to work with, you can use the Configuration Slicing plugin to modify the Max # of builds to keep.