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!
Related
When Maven deploys an artifact with a SNAPSHOT version defined, I understand it 'expands' the SNAPSHOT qualifier with the current datetime. For example,
<version>1.0.0-SNAPSHOT</version>
Might get deployed as 1.0.0-20200101-230000-1 if I deployed on 2020/01/01 at 11pm.
But I can't seem to find any information about that -1 at the end. Is that a build number? Why is it needed, and when does it get incremented?
Thanks
This number is incremented for every build of the same SNAPSHOT version, so as long as you build 1.0.0-SNAPSHOT the number increases by one for each build.
Why it is there, I can only speculate:
It gives you an absolute guarantee that the generated version number is unique (I admit that builds < 1s are not very realistic...)
It allows you to quickly see how many SNAPSHOTS were build.
I am working on a huge repo with a lot of branches in it. Most of them are already merged to master and some of them are waiting to be merged.
The need is for me to see which of them are touching into a specific directory.
For example, in this repo there are several APIs, let's say A, B, C, etc.
I would like to see which of the branches of this repo are trying to change A. That's why I mentioned a 'specific directory' above, but if there is an easier way to check, it's also acceptable.
I am not sure which way would be convenient to do that? Choosing to develop a script or are there any git native commands?
(This is not a complete answer. Just trying to bring some elements to the conversation.)
For a given branch, it would be quite trivial with something like
git rev-list --count <referenceBranch>..<featureBranch> -- path/to/directory/*
which would ouput a positive value only if the branch has touched the given directory since last reference state.
Now to loop over branches and execute the above test, I first thought about for-each-ref which, as names indicates, cycles through each ref in a given refset (here it would be refs/heads), but I don't yet see how to make these work together. probably just a loop in bash?
Interesting question indeed.
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 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?