I have completed build automation of Eclipse RCP application using maven/tycho.
Now I want to make it more seamless. So I am checking if we can auto-increment application version with every build.
for e.g. As you can see in attached picture, snapshot of .product file. enter image description here
Version is 1.2.0. So with every build, it should increase the version number 1.2.1, 1.2.2, 1.2.3, and so on, without changing the version manually in product file. Once I execute the parent pom(trigger the build), it should also increment app version and complete
the build process, all in one command that is mvn install.
can we achieve this using maven/POM.xml or please suggest any other solution??
You can use the goal parse-version of the org.codehaus.mojo:build-helper-maven-plugin (documented here: https://www.mojohaus.org/build-helper-maven-plugin/parse-version-mojo.html). This will store the parts of the current version in some properties (by default, parsedVersion.majorVersion, parsedVersion.minorVersion and parsedVersion.incrementalVersion). You can use such information to compute the next version number as you see fit.
Then, since you are using Tycho, you can pass these properties appropriately to the goal set-version of the org.eclipse.tycho:tycho-versions-plugin (https://tycho.eclipseprojects.io/doc/latest/tycho-release/tycho-versions-plugin/plugin-info.html).
Here you can see a simplified example using these two goals to remove the -SNAPSHOT and .qualifier: https://www.lorenzobettini.it/2020/02/remove-snapshot-and-qualifier-in-maven-tycho-builds/.
As I said, in your case, you'll have to do a few more operations to compute the next version number.
Related
I did my build numbers as 1, and then 2.
Does this matter - is it just a mater of preference as to how you do them?
The Build Number (or CFBundleVersion) is not shown in the App Store so for the user it does not really matter.
The purpose of the Build Number is that developers can distinguish different builds using the same Version (CFBundleShortVersionString).
Consider you are working towards a version 2.1.0. Before you publish this version on the App Store, you probably want to distribute Beta builds to testers. If they report any issues and you fix them, you will need to create and upload a new build but probably still use the version 2.1.0. In that case you would use the Build Number to distinguish the two version.
You can use whatever you like as a build version. Apple provides a tool to increase the Build Number in Xcode projects named agvtool.
Another way (and what I personally do) is to use the git commit count as the Build Number. This can be automated via a Build Phase. That way, every change that you make (and commit) automatically increases your Build Number.
I am currently implementing (I do not know if implementing is the appropriate word, but anyway) a semantic versioning in TeamCity. I have project level system parameters in which I store version number parts: system.major, system.minor, and system.patch. I have two build configurations:
First, we call it beta, is using the major, minor, and patch as-is and appends its build counter value to the version (i.e 1.0.0.X where X is beta's build count).
Second, we call it release, is using the major, and minor (but not patch) as-is and appends its build counter value as patch number (i.e 1.0.Y where Y is release's build count).
We want our versions to increment like following:
A beta build is run: 1.0.0.1
Another beta build: 1.0.0.2
A release build is run: 1.0.1.0
Yet another beta build: 1.0.1.3
The problem is, we want to use the release build's counter as patch number in beta build as well, without any human intervention. So far, I have read about people using assembly info or external VCS-tracked file to store the current version in last build step and parse the file in the first build step of every build configuration. This approach, though appears to be the standard way, is not welcomed by the project's manager, so I want to avoid using assembly info or another VCS-tracked file to store the version info. I have tried to use a powershell script build step in release configuration to set the parameter patch using:
Write-Host "##teamcity[setParameter name='system.patch' value='%build.counter%']"
yet, using teamcity[setParameter...] appears to take effect inside the running build and only on consecutive build steps. What I want is to set the system parameters in one build (release) and later, use their value in another build configuration (beta).
Is there any straight-forward way that I fail to see? If you have similar experience, can you point me to the right direction?
I am accomplishing something similar by doing an API call in a build step through powershell. Could this work for you? Do a GET request to find the current release build counter and then update the appropriate parameter with a PUT request.
I have the feeling I'm doing something wrong here as I have been digging around the net for a while (stackoverflow included of course) and yet that rendered no results!
In brief, I have a maven project set up with maven release plugin which works fine, increments the version correctly, checks in code in SVN, tags and deploys with no problem.
However, the need has arrived to also generate a script with each release which has to reference the jar generated. This means 2 things:
for the release version, change the script to contain the release version, commit it back in SVN (so it gets tagged etc)
following the release, the script has to be updated to contain the (next) SNAPSHOT version and committed back into SVN
For example, let's assume my current working version of the pom is 1.1.1-SNAPSHOT. As such my script.sh contains a reference to project-1.1.1-SNAPSHOT.jar.
When I perform a mvn release:prepare (assuming I will stick with the versions suggested by maven-release-plugin) the release version will become 1.1.1. At this stage, my script.sh should be changed to reference project-1.1.1.jar and committed back in.
Upon mvn release:perform all the 1.1.1 the tagging occurs, deployment to maven repo etc. And following that, my pom will be changed to 1.1.2-SNAPSHOT and committed back in SVN. At this point my script needs to be changed to reference project-1.1.2-SNAPSHOT.jar.
I figured out I can alter the script easily by using something like GMaven plugin -- and I have got the script in fact to kick in during prepare-resources phase (though maybe I need to look at another one?) however the biggest problem I see is retrieving the versions that maven-release-plugin has decided to use: in other words, how do I find out:
release version that maven-release-plugin has decided to use
next dev/SNAPSHOT version that maven-release-plugin will use
Once I get access to these I think I can get GMaven to execute the required code to change my script accordingly. (Though, if looking at the above scenario you can recommend a better way of doing this I would be more than glad to hear it!) Are there any properties like ${project.releaseVersion} (that doesn't work by the way) which could give me these 2 version numbers?
Thanks in advance!
Liv
I'm trying to setup my VisualStudio project to set the assembly version based on the latest subversion revision number as described on this page. But the version number always seems to lag one revision.
I've split out the assembly version attribute into a separate file, VersionInfo.cs, that is updated with a pre build event.
I'm using the following code to display the version number in the title of my form:
System.Reflection.Assembly assem = System.Reflection.Assembly.GetExecutingAssembly();
this.Text = "My Program Version: " + assem.GetName().Version.ToString();
Here's an walk through of what's happening.
I commit my project so that it is at the latest revision.
Using TortiseSVN I use show log to see that I'm at revision 55
I build my solution.
I then open VersionInfo.cs and see that the pre-build event correctly overwrote this file as
[assembly: System.Reflection.AssemblyVersion("0.1.55.*")]
Yet when I run the program the title bar displays and old version 0.1.52.20486
Next I open the project file in notepad, and change something, such as adding a blank line, and then save the file.
VisualStudio shows a notification that the project file has changed and prompts me to reload the project which I accept
Now when I build and run the program the form shows version 0.1.55.20645
I make a change to something in the project, and commit to SubVersion.
TortiseSVN confirms my working copy is now at revision 56.
I build my project and VersionInfo.cs is correctly updated to
[assembly: System.Reflection.AssemblyVersion("0.1.56.*")]
I try running the application again and the forms title shows 0.1.55.20750 rather then 0.1.56.xxxxxx
Also I've noticed that even if I rebuild/rerun my application the build number (the last number in the version number) is also not updated. It was my understanding that the asterisk would be replaced my a new number at each build.
Any one have any idea what's going on?
I haven't worked with the specific tool you are using but the tool I am using requires you to do an update on your sandbox after your commit. Has something to do with the tool using the revision number retrieved by the last update, not the last commit.
When you checkin a file, the revision number is incremented as you know. The problem is, you do not know what that revision number will be when you checkin - you only find out after checkin.
So, if you take the latest revision number, build your project, then checkin - the number used will always be out of date. What you really want is to be able to checkin, then get the revnum of the commit you've just performed, and then build your project with the correct version number.
Obviously this is not possible.
There is a way round it - use a CI system that builds your project immediately after checkin (through a post-commit hook). These will checkout the latest version you've just added, update your version.cs file, then build. The disadvantage is that your version.cs file will never contain the correct version number (unless the CI system then checks just it in again)
The best way to handle this is when you do your build.
I use Jenkins as my continuous build server instead of relying on doing a manual build on my system. If you don't use something like Jenkins (Hudson, Atlassian Bamboo and CruiseControl are three other popular Continuous Build servers), you should. This way, your official builds are not dependent upon a particular developer machine.
If you do use Jenkins, you can now use Nant or even Ant to help you manipulate your build. We are doing this now with Jenkins and Ant.
What I do is use msbuild.exe to build my project using Jenkins. Before I do a build, I use Ant to retrieve the Subversion revision number (actually, we use Jenkin's build number, but the theory is the same) to modify the assembly file with the correct version. Then, I do a build itself. The results is the correct Subversion revision number (err.. in our case the Jenkins Build Number) in the assembly file when it's built.
Come to think of it, you can probably do what you're doing now to set the Revision in the Assembly file. Jenkins will then build the project with the correct Revision number in the assembly file. You download the built package, and you'll see the correct version number in the title bar.
We've just started to use TeamCity as a continuous integration server. There's a problem we're trying to solve now:
We have a 'release' configuration, it has build versions set like this: 1.0.0.{0}
We also have a 'nightly build' configuration, which build number is: 1.0.0.0.{build.vcs.number.1}
So the first 2 digits are OK, Major+Minor versions. Third one is supposed to be set up manually as well according to our process (rarely though).
But as you can see, the last one increases with every 'release'.
The question is - how do I make TC copy the current 4th digit (or all of them) of 'release' to that of 'nightly build'?
One way to do it in 4.5 is to
Make nightly have a snap shot dependency on release.
find the internal build id of release.
use a build number format in nightly that looks like
%dep.releaseid.system.build.number%.{build.vcs.number.1}
where releaseid is the id you found in step 2. This will replace the whole %...% thing with the build number from release.
The TeamCity 4.5 Docs for dependency properties explains this and shows you how to find the internal id.
If you can know it in your build script, you can send it to team city during the build. Here are the instructions. I can think of a couple of strategies for getting the build number from the release build, none of them elegant. The most obvious would be to publish an artifact from the release build that is basically a text file with the build number in it, and retrieve that from your build script.