I'm developing a CI (Continuous Integration) for my application.
So, I'm using Jenkins with HockeyApp (equal to TestFlyApp).
The problem is that HopckeyApp only accepts new versions of an application if it different versions from the last one added, else it gives me an error of already existing version, and no update.
I was reading about the apple tool Agvtool to update the value CFBundleShortVersionString.
My main problems are,
how to do this in Jenkins automatically.
How to update the project repository (Git in my case),for the next build it knowing which is the last version that was updated, or any other option to keep track of the last version updated.
I am trying to do this, but other approach will be accepted has well.
Thanks in advance.
It is recommended to update the CFBundleVersion and not the CFBundleShortVersionString, see http://support.hockeyapp.net/kb/how-tos/how-to-do-versioning-for-beta-versions-on-ios-or-mac
The following blog posts goes through the whole setup and also shows how to automatically update the version number using git tags: http://monitzer.com/?p=75
Here is another approach using git to update the version number: https://gist.github.com/3395649
Related
I'm about to migrate Jenkins from version 2.190.3 to 2.204.6. As I know, I need to update installed plugins manually after updating Jenkins. I've got two questions here.
Does the Jenkins update affect current plug-in? or does it work the same as before updating the plug-in?
How can I find the expected side effects when I proceed with the update? Are there any tips?
Does the Jenkins update affect current plug-in? or does it work the same as before updating the plug-in?
Ans: Jenkins only update jenkin-core, it doesn't update current plugin. However, some plugin may be broken after update Jenkins-core due to incompatibility to new Jenkins-core
How can I find the expected side effects when I proceed with the update? Are there any tips?
Ans: we can not to be sure any expected side effect. So, when you proceed with the update, just go to "Manage Jenkins", it will shows you broken plugins that need to be upgraded to new version.
The recommended approach is to update all your plugins to "latest (compatible)" as possible, then upgrade Jenkins, the upgrade your plugins again.
Read the Upgrade Guide ans Change log. 2.204.6 is still very old. Recommend to 2.263.4 first as 2.277.x will break many plugins as a result of tables to divs migration.
Plugins are/must be upgraded separately from the app. Existing plugins may no longer be compatible, typically for security issues or a core plugins being decoupled. Some plugins may only work with newer core versions.
You should take a copy of your instance & config, update that and validate, then move to your real system.
As per the instruction provided in this link renamed one of the gerrit project. However now don't see this project changes in Open, Merged, Abandoned list. Something is wrong in the process of renaming?
Our gerrit version is - 2.13 and offline indexing will impact the productivity. Online is it possible to perform this particular project and changes indexing only?
You could try these two related options:
gerrit index start
gerrit index changes
Note: your Gerrit version is really old, you should think seriously in an update to a newer one.
Is there a way to sort the list of project spaces in Bitbucket? We started using Bitbucket for just a small section of the company now the entire company uses it and we have about 40 project spaces and Bitbucket and the order seems random. The original projects added years back are on the bottom (when we started using Stash 3.x) and all the newer ones (since upgrading to 4.x) are ordered alphabetically on top.
I'm sure I can poke around in the database to solve this but I'm looking for a UI- or API-based solution.
Projects in Bitbucket Server should sort in alphanumeric order. If you're not seeing that, you're experiencing a bug.
I work for Atlassian and I found and reported just such a bug when Bitbucket 5.0 was released. If perchance you're running one of the affected versions, you can resolve it by upgrading to a more recent version.
If you're running an older version than the ones listed in the above bug report, it's still possible you're running into a similar or the same bug - we list "affected versions" based on customer reports, so it's possible the bug existed on an older version but was never reported. On that bug report I provided a python script to easily reproduce the issue on a test instance, so if you can tell me the version of Bitbucket your company is running I can test it to see if it's reproducible.
Currently we are using axion-release-plugin to control our release process. Now we would like to drop the SNAPSHOT and introduce the build number in our release process. So that we can achieve CI.
Basically currently we are using version 1.0.0-SNAPSHOT and now we need something like 1.0.0-BUILDNUMBER or 1.0.BUILDNUMBER from Jenkins.
Please provide any solution or plugin we can use with gradle.
I'm actually quite happy with nebula-release-plugin developed by NetFlix. It can generate a unique version number based on branches and tags in your git repo.
By default it counts with using git flow, but you can reconfigure the behaviour. Take a look :)
I wanted to know how you deal with the versioning of your iOS apps. CFBundleShortVersionString should match with the version submitted to iTunes Connect and CFBundleVersion is your unofficial build number.
For CFBundleShortVersionString often the format {MajorVersion}.{MinorVersion}.{Revision} is used. One could use the {Build} number for the CFBundleVersion. Another possibility would be to use some sort of revision number from the VCS or in my case the SHA1 hash of the commit of GIT.
If you submit an app to the app store the CFBundleVersion is used to determine if your app is an update. It is only allowed to use digits and the dot separator here and it should be higher than the older version. So using a hash doesn't work here and there is no revision number in GIT. Once the app is ready for release the app can use the same value for CFBundleShortVersionString and CFBundleVersion if you have some different naming for the build number which is not compatible with the app store.
Currently the only thing which comes to my mind is to manually enter the version number if the app is ready for release. So you start counting if you have v. 1.0.0 and increases the number if you provide a new release. If you have a new beta version (e.g. you are planning a new release 2.0.0), what do you use for CFBundleVersion? Or what if you use continous integration and a new build is generated each day at midnight?
Also is there an automated process which connects Xamarin Studio, Info.plist and GIT so that for example the build number is increased on each commit? And how does such a process look like?
Bonus question: What information do you show the user in the about dialog of the app?
This is not full answer on how to handle inserting version into Info.plist and iOS versioning but instead how MonoDevelop/XamarinStudio creates version number from GIT commits. Which you can probably use to hack some way to update your Info.plist.
https://github.com/mono/monodevelop/tree/master/scripts
This folder has 3 files .sh and .bat are just to compile third file(.cs) and execute it.
So if you look into this .cs file you will see:
How to get "git.exe"
How to run blame on version.config(this is file where you manually insert versions like(5.5, 5.7, 5.8...)
How to run "rev-list --count " + hash + "..HEAD" which means count all commits between last change to version.config file and current commit. So if version.config was changed 143 commits ago, version will be 5.5.0.143, you can of course still use 3rd place for service packs.
And also some output of this informations like for example buildinfo which can then be used by other parts of build process to insert into Info.plist.
I hope this helps you to solve your problem.