Hy, I am using 3.2.5 maven.
I have a problem with releasing. I use the release:prepare to Tagging from trunk and create version without snapshot. The preapre run clean and verify by default after Transforming but I modified this setting to celan. So the prepapre goal dont create build.
I use release:perform to checkout from tag and build. I woudlike add manifest.mf with svn revision number to build.
This is ok but the revision number in build equal the revison number of Trunk.
For example: Tag revision = 7000 and Trunk revision=7001. When I make a build from tag it make revision number 7001.
I chechked the Tag manualy and create build with install and the revision number as soon as than perform.
I tagging manualy and create build with install and the revision number correct so the revision number eqaul the revision number of tag.
It visible the revision number of tag and trunk in svn. When revison number of tag 7000 but I get 7001 in build (tagging with prepare).
Can you help me?
Thank you!
Related
I am using gradle, I added the plugin
plugins {
id 'pl.allegro.tech.build.axion-release' version '1.14.0'
}
now when I am running
./gradlew currentVersion
I am getting
Project version: 0.1.0-SNAPSHOT
I tried adding a gradle.properties that contains
version=0.0.1-SNAPSHOT
But when running
./gradlew currentVersion
it still returns 0.1.0-SNAPSHOT
I'd like to know where that's coming from and if it's possible to use the value from gradle.properties, or what's the best way to use the version with the plugin.
Thanks.
If it still return 0.1.0-SNAPSHOT, that's by design. As stated by Adam Dubiel from Allegro:
... by design axion-release does not include version number in build.gradle. Philosophy of axion-relese is that version is not declared in files, but is a product of source code version tracked by SCM - git.
Then your can have a look at the documentation or at Allegro tech blog:
The flow of axion-release-plugin is simple. Each time you start a build it looks for the version tag closest to current commit and extracts the version number from it. If you happen to be on a tagged commit, you operate on release version. If not, patch version is increased and SNAPSHOT suffix is appended.
Here is an example of the flow:
$ git tag
project-1.0.0
$ ./gradlew currentVersion
1.0.0
$ git add . && git commit -m "I've just changed something"
$ ./gradlew currentVersion
1.0.1-SNAPSHOT
$ ./gradlew release
$ git tag
project-1.0.0 project-1.0.1
$ ./gradlew cV # gradle magic - currentVersion
1.0.1
I hope this helps, despite the late reply
I'm currently learning Maven and I've been doing some testing with gitflow-maven-plugin, I have set up and get it work, now it can change the last digit of the versioning (so if the release version for master branch is 1.0.0, develop version is 1.0.1-SNAPSHOT), I tried to control the change of the digit by using :
mvn -B gitflow:release -DversionDigitIncrement=1
I tried to set DversionDigitIncrement to 0, 1, 2 but the only number changed is the last digit (which is the 'PATCH'), how can I test if the other two numbers change properly? Which commands I should ues or do I need to change configuration in POM file?
Been messing around for a whole day now. Many thanks. (I wanted it to follow semantic versioning naming rule)
try to use it after a release-start :
mvn -B gitflow:release-start
mvn -B gitflow:release-finish -DversionDigitToIncrement=0
mvn -B gitflow:release -DversionDigitToIncrement=0
OR if you want to change develop version at release-start :
mvn -B gitflow:release-start -DcommitDevelopmentVersionAtStart=true -DversionDigitToIncrement=0
In your case, 0 to major and 1 to minor
https://github.com/aleksandr-m/gitflow-maven-plugin#additional-goal-parameters
I have a Jenkins multiphase job that
gets an update from version control (Subversion)
does a Maven build. Couldn't be more cut and dry.
The 1. above, svn update, does return a latest revision number. I would like to fetch that into 2. so that the build and its associated artifacts do have that number pinned to them, if any way possible in the artifact name itself but, if not, in the build history. Is there a way to do it and how (e.g. using the subversion or another plugin)?
I am using the buildnumber plugin to fetch the build number and generate a small text file that is contained inside my WAR artifacts, which makes it subsequently available via HTTP. But to see it, one must either first deploy the artifact or at least extract its contents. I would like it more readily visible in Jenkins.
You should take a look at How to get SVN revision number in Jenkins Workflow Plugin? - He solved the problem with:
def revision = 'svn info'.execute().in.text.split('\n').find { it.startsWith('Revision') }.split(':')[1].trim()
He's obviously using the latest Jenkins version, but if you're using one of the old Jenkins versions you can simply run the following command and parse the result to get the revision number you want:
svn info -r HEAD
BTW you can use a Jenkins constant too. In the browser you can open http://your-jenkins-host/env-vars.html/ and you will find a constant named SVN_REVISION. Each job build keep the SVN revision into that variable.
I have big problem with configuring TC. It's 10.0.2 version.
I want build chain like this:
Main - Restore nuget and rebuild solution.
Code analysis - Analyse code result(do not checkout) use Main as dependency.
Publish - Publish to Azure - Use result of Main.
I set Main to:
Build numer format:%build.counter%.%build.vcs.number....%
VCS checkout dir: auto
Code analysis
Build number format:%build.counter%.%dep.<mainId>%.%build.vcs.number...%
VCS checkout dir:%dep.<mainId>.build.default.checkoutDir%
And the main dir is: 55660246e9f668c3
And Code Analysis searching in: 9ccd5731845f5aba
So it's wrong. Why?
Why?
EDIT:
What I set VCS checkout directory in "Code Analysis" build configuration to hardcoded directiory name of "Main" e.x. to 55660246e9f668c3 then it work.
So the problem is with %dep.<mainId>.build.default.checkoutDir%
You can set up a snapshot dependency, that builds from the same chain. This will ensure that the same branch, from the same root, with the same revision number (point in time) is checked out to the directory. If you use an artifact dependency, in addition to the snapshot dependency, you can achieve the same point in time consistency. So after your step 1 build runs, regardless of what new changes exist, your second build will be working with the same files your first had.
How do I find the TeamCity revision number of an artifact's last checkin? (NOT the lastest build number)
Teamcity populates a predefined parameter build.vcs.number.<VCS root ID> which holds the revision number of the check-in. See Predefined Build Parameters for more information.
From my understanding the configuration parameter "teamcity.build.id" is used as the artifact revision number.
On Linux environment, the build artifacts can be access from the location -
"/opt/TeamCity/data/system/artifacts/project.id/buildConfName/teamcity.build.id"
Cheers