I have a build-server, implemented with team-city.
Until now, I have an input parameter that represent the first 3 parts of the version number (x.y.z) = %Version.Number%
When I compile my exe files, I set the file version to be:
%Version.Number%.%build_number% and then I get a 4 parts version number.
The problem with that solution is that there is no connection between the first 3 parts of the version number and the build number.
Now, I want to find a way to have a different set of %build_number% for each %Version.Number%.
I will illustrate the problem with an example:
On the first build when %Version.Number% = 15.3.2 - the version number will be 15.3.2.0 .
On the second build when %Version.Number% = 15.3.2 - the version number will be 15.3.2.1 .
Now, on a new build when %Version.Number% = 16.0.0 - the version number will be 16.0.0.2
and I want to be 16.0.0.0.
Thanks.
Two ways to handle this, at least:
Use the Version Number Plugin -
it will allow you to reset the "running" build number whenever you like -
simply set the next-build-number to '1' whenever the major release is increased
(as a bonus, it also lets you format the version-number with leading-zeroes and such).
Create a new job whenever you increase the major release number -
copy build_job_15.3.2 to build_job_16.0.0
edit the version-number in build_job_16.0.0 to be '16.0.0'
optional: disable build_job_15.3.2
Now you can run build_job_16.0.0, and the build number will start with '1'
(this method is a bit tedious, but allows you to continue building 15.3.2 releases, if needed).
You are able to reset the build number counter in the General Settings of the Build Configuration. Is that not sufficient for your scenario?
Related
I have the git commits and the tags as below
The tag of the latest commit is 12.0.0-beta.6. When I run GitVersion, the result is as below
So the build number on TeamCity should be 12.0.0-beta.6, but I don't know why the GitVersion generates build number 12.0.0-beta.6+8 on TeamCity.
My build steps are as below
Does anyone know why GitVersion generates the redundant "+8" after the FullSemVer?
How to remove this dedundant "+8"?
Thank you very much.
The +8 is metadata and not actually part of the version number. In the documentation for the version variables, BuildMetaData is described as:
The build metadata, usually representing number of commits since the VersionSourceSha.
You can see the same value 8 exposed as CommitsSinceVersionSouce and this should increase with every commit made to the branch since its "version source", which in this case is the tag 12.0.0-beta.6 made on commit 549a1d.
The metadata does not increase with every build, but with every commit. I can see how the current language is confusing and the name BuildMetaData does not help. Since BuildMetaData is an exposed variable, we can't change its name, but I've submitted a PR that will hopefully clarify its documentation.
Read carefully and understand at least part of GitVerson docs (paragraphs 1+2)
The shortest possible extraction
GitVersion will increment the metadata for each build so you can tell
builds apart. For example, 1.0.0+5 followed by 1.0.0+6. It is important
to note that build metadata is not part of the semantic version; it is
just metadata!
The goal versions:update-properties produced the following output:
10:52:25,255 INFO - --- versions-maven-plugin:2.7:update-properties (default-cli) # release-plugin-test-new-bo ---
10:52:32,605 INFO - artifact de.continentale.muv:coutil: checking for updates from nexus
10:52:32,666 INFO - Subincremental version changes allowed
10:52:32,682 INFO - Updated ${coutil.version} from 7.0.0-SNAPSHOT to 7.0.1-RC0002
I set the parameters -DallowIncrementalUpdates=false, and also -DallowMinorUpdates=false and -DallowMajorUpdates=false, which is reflected in the line "Subincremental version changes allowed". Nevertheless, the version was upgraded by changing the third number in the version.
This behaviour is unexpected and also not idempotent (the next run replaces 7.0.1-RC0002 by 7.0.1).
I tried to figure out why that happens from the documentation and also from the Javadoc and source code but got lost somewhere in Maven version comparison.
Can someone enlighten me? Is this a bug, or do I need to configure things differently to avoid the updates on the third number?
Some debugging lead to the conclusion that for 7.0.0-SNAPSHOT, the goal versions:update-properties with the parameters as above does about the following:
Create an upper bound by incrementing the third number (in this case, the upper bound is 7.0.1-SNAPSHOT).
Look for the largest version below that bound (for Maven 7.0.1-RC0002 is smaller than 7.0.1-SNAPSHOT).
IMHO, the code does not behave properly because there is actually an incremental change in the version number although I set the respective property to false.
SonarQube Metrics graphs are not being displayed on my project dashboards behind the total numbers and Quality Gate ratings.
Current versions of SonarQube and plugins and MySQL 5.7. I am creating a new SQ project through its Administration->Projects->Management->Create Project and then performing analyses as follows (anything capitalized is either a variable or anonymized): *
MSBuild.SonarQube.Runner.exe begin /k:KEY /v:VERSION /d:sonar.host.url=http://localhost:9000/ /d:sonar.login=TOKEN /d:sonar.projectDate=YYYY-MM-DDTHH:MM:SS+0000
MSBuild.exe /maxcpucount /nr:false /nologo /target:rebuild /verbosity:quiet PROJECT\PROJECT.sln
MSBuild.SonarQube.Runner.exe end /d:sonar.login=TOKEN
I have tried VERSION equal to a constant value "1.0" and VERSION equal to a string of the UNIX time (seconds since 1/1/1970) of each git commit I analyze. I've also tried configuring project leak periods of the last 90 days and also previous_analysis, though I think that would only affect the graphs in the right column. If someone could tell me what I am doing incorrectly, I would appreciate it.
* These are examples of the commands executed by a Python script that is iterating over a list of git commit hashes and their associated timestamps, in increasing order, to populate the project history. The python script in turn is mimicking a Jenkins job that will eventually take over calling SonarQube.
Background Tasks page:
Your project homepage screenshot shows the graph in the leak period, but not extending left into the Overall section.
This is going to be a question of your analysis date and your definition of "leak period". If your leak period is set to previous_version, then you need to take a look at the sonar.version values in your analyses. So far, it looks like all your analyses are leak period analyses, which is why nothing has filtered left into the overall view.
I need to pull certain numbers from the console output of a Jenkins build, and then plot that data on a graph. If my output is:
+ echo -153
-153
+ echo master count: 13596
master count: 13596
Finished: SUCCESS
I want to pull the master count and -153. The master count is total number of errors while the -153 is the change of errors from two builds. I then want to make a graph using those 2 numbers.
So my question is, how do I send those two sets of data from the console to a graph in jenkins? The numbers will change over time and I wish to be able to see the trend in errors.
Assuming that the shell code you listed above is under your control, the easiest way to do this is to echo the output to a CSV file instead of / as well as to the console, and then use the Jenkins Plot Plugin to display the results.
This is exactly what the Plot Plugin is for.
You need to change your shell build step (or other part of the build) to create
a separate file for each value that you want to plot.
They need to be of the form:
YVALUE=<value>
In your example you would need a file "mastercount.txt" with:
YVALUE=13596
and another file called "diffcount.txt" with:
YVALUE=-153
Then under post-build actions you need to configure the plot-plugin to pick up these files and generate plots.
I setted AssemblyVersion attribute to this:
[assembly: AssemblyVersion("1.0.0.*")]
It is increasing according to change of assembly and time. Now it is: {1.0.0.20042} and if I don't change cs files inside assembly it doesn't increase. But if I change the one of class file in this assembly, version isn't increasing just one. If I didn't misunderstand the articles it is increasing depend on time. But I want to set this increament depend on build number.
Is there any way to learn build number from this version number or to set it's increament 1 ?
I use Auto Version Increment for Visual Studio. It's free and works for VS2005/08 and has a separate version for VS2010.
You can select all sorts of policies on build incrementing, including per-build increment and time based build numbers.
If you've got multiple projects and want to keep the version numbers the same, you can create a shared AssemblyInfo.cs between all projects, then increment the build version in that.