simpler autobuild-logic from .pro-file version (inkl releases)

[nefarius2001]

Hi,

I'd propose a simpler logic for autobuilds (with artifacts), codeQL and github-releases:

• push or pull-request
  • to master: autobuild&artifacts, codeql (no release)
  • to "autobuild" branch: autobuild&artifacts (no codeql, no release)
• tags:
  • if version in .pro file contains "dev": autobuild&artifacts, (no codeql, no release)
  • if version in .pro file contains "beta": autobuild&artifacts, pre-release (no codeql)
  • if version in .pro file contains neither: autobuild&artifacts, release (no codeql)

Benefits:

• releases are not implicitly dependant on the name of the git-tag
• enforces dealing with the .pro-file (and Changelog) when filing a commit and avoids events like Build: Show proper version number for beta releases #1079. I will continue to implement a decent automation for that process.

Let me know what you think about this.

[pljones]

Tags: I think the magic I want is that if I tag a master commit, I want Jamulus.pro rewritten according to the versioning rules for that tag and have the updated version committed to master -- and it's that commit that then triggers the master build. That would need to run CodeQL, the same as any change to Jamulus.pro needs to for pushes / PRs to master.

This way, anyone pulling master has the correct version in Jamulus.pro automagically.

[nefarius2001]

I have a stub for a script, that:

• that edits the .pro
• opens editor for you to edit the changelog
• creates commit and tag
• edits the .pro (back to "dev")
• opens editor for you to edit the changelog (back to "dev")
• creates a commit
  (https://github.com/nefarius2001/jamulus/tree/autobuild/releasescript)

I'm still a bit confused. Do you want someone who pulls master to:

• get the very latest development? Then most of the time they get an intermediate state, correctly defined by a intermediate "dev" version
• get the latest release? Then we need to use the repository branches different than before. Currently the "master" branch holds a release/beta only until the next commit/merge. (same applies for "the latest beta or release")

[pljones]

Jamulus.pro at HEAD of master should have a version that reflects the tag on HEAD of master.

• If there is no tag for the commit, then it's a dev version.
• If there's a beta tag for the commit, then it's a beta version.
• If there's a release tag for the commit, then it's a release version.

All with the appropriate version formatting.

So, if a code pull request is merged to master - nothing happens - it's just after that last tag (or lack thereof).

If I push a tag to master, then Jamulus.pro needs to get automatically updated, committed and the tag moved to point to the new commit. (Assuming it's a tag that affects the Jamulus.pro version.)

This then means my local and upstream are out of sync -- but code isn't different, just the Jamulus.pro version. If I build without pulling upstream, I still won't get my tag taken into account, so I need to sync with upstream. Which is correct behaviour.

[pljones]

At work, we've a lot of different accumulated processes for releases from the "No-release release" approach -- which actually means "every commit is a potential release" -- through to manually assembling a release. In between, there's "Tell Jenkins to spit out a release" - which it does by updating from a development version to a release version number, committing the change to Stash, doing the build and publishing to Artifactory - then bumping the version to the next development version.

Which is a good point... potentially, master should never have HEAD tagged as a release version, it should always be a dev version. However, tagging HEAD as beta or release should make the new build, as above, then edit the Jamulus.pro version back again to dev and commit. If you really want to build manually - rather than downloading the CI artifacts - you have to manually check out the tag.

One reason for "manually checking out the tag" can be if a lot of change has been committed to master but it's not ready for release and there's suddenly the need to push out a bug fix (e.g. someone finds a serious security flaw - something we'd want fixed immediately). Check out master, make and test the fix, commit. Then check out the last release, back port the fix and test it, branch and commit to the fix branch, then release a new version from there.

[pljones]

Finally had a good read of the code in Jamulus.pro...

Currently, Jamulus.pro magics up a build version with

git describe --match=xxxxxxxxxxxxxxxxxxxx --always --abbrev --dirty

Things I'd do differently:

1. If this is a git repo
   1. run git describe --tags --always --abbrev=10 --dirty --exclude=latest
   2. that should give something like:
      • r3_7_0beta3-110-g3f916fd9df-dirty - in progress development, local tree not clean
      • r3_7_0beta3-110-g3f916fd9df - in progress development, clean local tree
      • r3_7_0beta3 - tagged beta release
      • r3_6_2-167-g80e1d2325a - older dev release
      • r3_6_2 - tagged release (--exclude=latest stops this currently getting called latest)
   3. use that value directly for the version
2. Otherwise (not from git),
   • this is an uncontrolled build - we do not know what changes have been made
   • use the version in Jamulus.pro plus something more explicit than nogit -- unofficial, perhaps
3. Of course, people are editing Jamulus.pro to set the version, anyway. Can't be helped.

Examples above from:

peter@fs-peter:~/git/Jamulus$ git checkout master
peter@fs-peter:~/git/Jamulus$ git describe --tags --always --abbrev=10 --dirty --exclude=latest
r3_7_0beta3-110-g3f916fd9df
peter@fs-peter:~/git/Jamulus$ git checkout r3_7_0beta3
peter@fs-peter:~/git/Jamulus$ git describe --tags --always --abbrev=10 --dirty --exclude=latest
r3_7_0beta3
peter@fs-peter:~/git/Jamulus$ git checkout 80e1d232
peter@fs-peter:~/git/Jamulus$ git describe --tags --always --abbrev=10 --dirty --exclude=latest
r3_6_2-167-g80e1d2325a
peter@fs-peter:~/git/Jamulus$ git checkout latest
peter@fs-peter:~/git/Jamulus$ git describe --tags --always --abbrev=10 --dirty --exclude=latest
r3_6_2

as the build reference. Currently the only problem is the .qm files. They're not in .gitignore. That's a separate issue, though. After doing a build, describe says it's -dirty.

[pljones]

The replace might -- VERSION=$$replace(VERSION, r, ""); VERSION=$$replace(VERSION, _, .) maybe. Might be worth trying.

[pljones]

It needed a slight adjustment... $$replace(VERSION, r, "") did exactly what I asked. -dirty became -dity... So running with --dirty=-DIRTY is a workaround. (Or $$replace(VERSION, -dity, -dirty) if preferred.)

Project MESSAGE: building version "3.7.0beta3-113-g090e8acadf-DIRTY" from git

Given that Volker is currently running a dev build on the default directory server that is where update checks take place, we are sure that X.Y.Zdev-hex isn't seen as greater than X.Y.Z. My git doesn't recognise the commit he's using. However, if I check Swedish Open Jam 2 using 3.6.2dev-86143479, it would have got 3.7.0beta3-93-g86143479b0 with my proposed scheme (given we've used 3.7.0 tags).

Until the version check code changes, we should stick to old style naming - so tags should follow suit: prior to 3.7.0 release, tags need to be 3.6.2xxx.

The other alternative is a temporary hack in Jamulus.pro -- $$replace(VERSION, 3.7.0, 3.6.2)...

[pljones]

Here's the suggested patch: https://gist.github.com/pljones/0364dc6b2a4aed8142efc4f2037d302a
(with DIRTY and no hack of version number.)

[npostavs]

Tsk... I'd sort of assumed qmake could do a regexp replace but it can't. Mmm... I can't even see a way to "delete the first character of a string"

Maybe split, then take-first and join?

[pljones]

The two-replace run I did in the gist I posted worked how I was expecting.