Autobuild: Cleanup analyze_git_references.py

[hoffie]

Short description of changes

This PR refactors .github/actions_scripts/analyze_git_references.py. It drops unused variables and logic, it replaces comments by (hopefully) well-named functions and fixes multiple coding style issues. It also adds a check to fail if we push release tags without proper Jamulus.pro VERSION.

Most of the changes are internal to the script and are not supposed to show a change in behavior from the outside.
Some of the changes do have an effect on the output though, which can be seen in the following output variable cleanups:

• The following variable is not referenced in the Autobuild workflow at all and can therefore be safely dropped from the script output: PUSHED_NAME

• The following variables are referenced in the Autobuild workflow and are declared as outputs, but those outputs are not referred to anywhere. Therefore, they can safely be dropped:

  • PUSHED_NAME
  • X_GITHUB_WORKSPACE

• The following variables are only relevant for releases (PUBLISH_TO_RELEASE=true). Therefore, we only need to calculate their value for actual releases:

  • RELEASE_TITLE
  • RELEASE_TAG
  • IS_PRERELEASE

As I suspect this PR diff is rather hard to read, I'm providing output diffs (before/after this PR, last updated 2022-03-09 11:40 CEST) for the most relevant scenarios as proof that those cases still look sane:

Simulated push to a branch:

$ git status
On branch master
$ export GITHUB_WORKSPACE=. GITHUB_REF=refs/heads/somebranch; diff -u <(./.github/actions_scripts/analyse_git_reference.py | grep ::set | sort ) <(./.github/actions_scripts/analyse_git_reference_new.py | grep ::set | sort ) | grep ::set
-::set-output name=IS_PRERELEASE::true
-::set-output name=JAMULUS_VERSION::3.8.2dev-f5434765
 ::set-output name=PUBLISH_TO_RELEASE::false
-::set-output name=PUSHED_NAME::somebranch
-::set-output name=RELEASE_TAG::releasetag/somebranch
-::set-output name=RELEASE_TITLE::Pre-Release of "somebranch"
 ::set-output name=RELEASE_VERSION_NAME::3.8.2dev-f5434765
-::set-output name=X_GITHUB_WORKSPACE::.

Simulated push to a release tag:

$ git co r3_8_2
HEAD is now at 36cb9002 Update to version 3.8.2 for release
$ git status
HEAD detached at r3_8_2
$ export GITHUB_WORKSPACE=. GITHUB_REF=refs/tags/r3_8_2; diff -u <(./.github/actions_scripts/analyse_git_reference.py | grep ::set | sort ) <(./.github/actions_scripts/analyse_git_reference_new.py | grep ::set | sort ) | grep ::set
 ::set-output name=IS_PRERELEASE::false
-::set-output name=JAMULUS_VERSION::3.8.2
 ::set-output name=PUBLISH_TO_RELEASE::true
-::set-output name=PUSHED_NAME::r3_8_2
 ::set-output name=RELEASE_TAG::r3_8_2
 ::set-output name=RELEASE_TITLE::Release 3.8.2  (r3_8_2)
 ::set-output name=RELEASE_VERSION_NAME::3.8.2
-::set-output name=X_GITHUB_WORKSPACE::.

Simulated push to a pre-release tag:

$ git co r3_8_2rc1
HEAD is now at c4450193 Update version to 3.8.2rc1
$ git status
HEAD detached at r3_8_2rc1
$ export GITHUB_WORKSPACE=. GITHUB_REF=refs/tags/r3_8_2rc1; diff -u <(./.github/actions_scripts/analyse_git_reference.py | grep ::set | sort ) <(./.github/actions_scripts/analyse_git_reference_new.py | grep ::set | sort ) | grep ::set
 ::set-output name=IS_PRERELEASE::true
-::set-output name=JAMULUS_VERSION::3.8.2rc1
 ::set-output name=PUBLISH_TO_RELEASE::true
-::set-output name=PUSHED_NAME::r3_8_2rc1
 ::set-output name=RELEASE_TAG::r3_8_2rc1
 ::set-output name=RELEASE_TITLE::Release 3.8.2rc1  (r3_8_2rc1)
 ::set-output name=RELEASE_VERSION_NAME::3.8.2rc1
-::set-output name=X_GITHUB_WORKSPACE::.

Simulated push to a nightly tag:

$ git co r3_7_0devNightly1
HEAD is now at cae8d2d6 Prerelease r3_7_0devNightly1
$ git status
HEAD detached at r3_7_0devNightly1
$ export GITHUB_WORKSPACE=. GITHUB_REF=refs/tags/r3_7_0devNightly1; diff -u <(./.github/actions_scripts/analyse_git_reference.py | grep ::set | sort ) <(./.github/actions_scripts/analyse_git_reference_new.py | grep ::set | sort ) | grep ::set
 ::set-output name=IS_PRERELEASE::true
-::set-output name=JAMULUS_VERSION::3.7.0devNightly1-cae8d2d6
 ::set-output name=PUBLISH_TO_RELEASE::true
-::set-output name=PUSHED_NAME::r3_7_0devNightly1
 ::set-output name=RELEASE_TAG::r3_7_0devNightly1
 ::set-output name=RELEASE_TITLE::Release 3.7.0devNightly1-cae8d2d6  (r3_7_0devNightly1)
 ::set-output name=RELEASE_VERSION_NAME::3.7.0devNightly1-cae8d2d6
-::set-output name=X_GITHUB_WORKSPACE::.

Note: Releases which use other separators than _ will no longer be considered releases. This affects some nightly versions (r3.8.0devNightly1) which have been tagged differently than previously (r3_7_0devNightly1). I'd like to keep it like that as we should be consistent in our tags (although I'm not opposed to switching from rA_B_C to the more common vA.B.C, but that's out-of-scope for this PR.)

Simulated push to a non-version tag starting with r (is this case relevant?):

$ export GITHUB_WORKSPACE=. GITHUB_REF=refs/tags/rnon-release-tag-starting-with-r; diff -u <(./.github/actions_scripts/analyse_git_reference.py | grep ::set | sort ) <(./.github/actions_scripts/analyse_git_reference_new.py | grep ::set | sort ) | grep ::set
-::set-output name=IS_PRERELEASE::true
-::set-output name=JAMULUS_VERSION::3.8.2dev-f5434765
-::set-output name=PUBLISH_TO_RELEASE::true
-::set-output name=PUSHED_NAME::rnon-release-tag-starting-with-r
-::set-output name=RELEASE_TAG::rnon-release-tag-starting-with-r
-::set-output name=RELEASE_TITLE::Release 3.8.2dev-f5434765  (rnon-release-tag-starting-with-r)
+::set-output name=PUBLISH_TO_RELEASE::false
 ::set-output name=RELEASE_VERSION_NAME::3.8.2dev-f5434765
-::set-output name=X_GITHUB_WORKSPACE::.

Simulated push to a non-version tag not starting with r:

$ export GITHUB_WORKSPACE=. GITHUB_REF=refs/tags/non-release-tag; diff -u <(./.github/actions_scripts/analyse_git_reference.py | grep ::set | sort ) <(./.github/actions_scripts/analyse_git_reference_new.py | grep ::set | sort ) | grep ::set
-::set-output name=IS_PRERELEASE::true
-::set-output name=JAMULUS_VERSION::3.8.2dev-f5434765
 ::set-output name=PUBLISH_TO_RELEASE::false
-::set-output name=PUSHED_NAME::non-release-tag
-::set-output name=RELEASE_TAG::non-release-tag
-::set-output name=RELEASE_TITLE::Release 3.8.2dev-f5434765  (non-release-tag)
 ::set-output name=RELEASE_VERSION_NAME::3.8.2dev-f5434765
-::set-output name=X_GITHUB_WORKSPACE::.

CHANGELOG: Autobuild: Improved analyze_git_references.py script
(I'll likely merge all my Autobuild refactoring-related Changelog entries in the end)

Context: Fixes an issue?

Improves readability/maintenance.

Does this change need documentation? What needs to be documented and how?

No.

Status of this Pull Request

Ready for review.

What is missing until this pull request can be merged?

I'm still planning the following tests on my fork:

• Push a release tag (check release/changelog): Artifact names are correct, Artifact names are connect
• Push a pre-release tag (check release/changelog): Variables are correct, Artifacts still building
• Push to a branch: Variables are correct Artifacts names are correct
• A PR (this very PR should suffice for this test): Variables are correct, Artifact names are correct

Checklist

• I've verified that this Pull Request follows the general code principles
• I tested my code and it does what I want
• My code follows the style guide
• I waited some time after this Pull Request was opened and all GitHub checks completed without errors.
• I've filled all the content above

[ann0see]

What happens if there is a tag without r* on a autobuild branch/non autobuild branch? I’m not sure if we wanted that to build (I‘m unsure if we even use non releatags anymore).

[hoffie]

What happens if there is a tag without r*

I've added example output for that as well (all assuming that Jamulus.pro was not updated to match this pseudo-version).
Short answer: Auto build runs, no release will be created. I think that sounds reasonable?

on a autobuild branch/non autobuild branch?

There is no such distinction. A tag is not associated to a branch. It may (and often will) reference a commit which also happens to be on a branch, but that's not relevant for the logic here. What is relevant is the distinction of tags starting with r (but not matching A_B_C) vs. tags without a starting r. I've added both outputs above.

I’m not sure if we wanted that to build (I‘m unsure if we even use non releatags anymore).

I guess it could be adjusted, although I don't see what the downside of running a build is there?
As you say, I don't think we (jamulussoftware) use such tags, so it's not that relevant.

[hoffie]

Short answer: Auto build runs, no release will be created.

Umm, that's not the complete truth.

• rSOMETHING does create a pre-release. Although it has already been like that, I don't think it should. I'll check if it can be adjusted.
• SOMETHING doesn't.

[hoffie]

rSOMETHING does create a pre-release. Although it has already been like that, I don't think it should. I'll check if it can be adjusted.

Updated.

I've also added a test case for nightlies to the PR description (@ann0see please also note the comment about the tag format).

[softins]

Looks good to me, and a lot tidier.

[ann0see]

So we need to remember using _ instead of . everywhere on git.

(I'm not a fan of two different versions of describing the same version, but as far as I remember it is needed somehow).

[hoffie]

So we need to remember using _ instead of . everywhere on git.

Yes.

(I'm not a fan of two different versions of describing the same version, but as far as I remember it is needed somehow).

Agreed. I'd be more happy if we were following the more common vA.B.C scheme. If we decide to go that route we should do that properly and adjust all places though. :)
It's just that I think it will cause some breakage (e.g. people checking out git tags have to adjust, scripts may have to be updated, etc.).
If you want to make it happen I suggest opening an issue... :)

[ann0see]

I don’t know Python well, but I trust your tests (they should include the most commonly used features we need).