feat: added ignore-detached-head command line flag

[qvistgaard]

We have experienced, when someone is committing changes while our build process is running with and including commits, for example when updating pom file version, it breaks the build process, simply ignoring the detached head fixes it for us.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[qvistgaard]

@PSanetra friendly reminder

[PSanetra]

@qvistgaard thank you for the reminder.

I will think about this later today. I think it should be possible to solve that issue without this special flag. Maybe you can add an integration test in the integration_tests directory which reproduces the observed issue.

[PSanetra]

@qvistgaard can you take a look at 3db11b0? This test checks if the git semver next command does work correctly in the detached HEAD state. I could not reproduce the error you described via this test.

[qvistgaard]

@PSanetra Sorry for the late reply. you can use this set of commands to reproduce:

git init
echo "1.0.0-SNAPSHOT" > version.txt
git add version.txt
git commit -m "fix: added version.txt"
git checkout -B release
echo "1.0.0" > version.txt
git commit -a -m "ci: set version"
git tag v1.0.0
git checkout master
echo "1.0.1-SNAPSHOT" > version.txt
git commit -a -m "fix: set version"

Final tree:

* 56a03f2 (HEAD -> master) fix: set version
| * ceda671 (tag: v1.0.0, release) ci: set version
|/  
* 284712b fix: added version.txt

Running without the new flag causes this error

$ git-semver next
FATA[0000] Latest tag is not on HEAD. This is necessary as the next version is calculated based on the commits since the latest version tag. (tag: refs/tags/v1.0.0; commit: e18d4273daabc5b9df2cc09365132796c0a4b9d0)

With the flag removes this issue

$ git-semver next  --ignore-detached-head
1.0.1

[PSanetra]

@qvistgaard ok, the problem is that the commit with the tag v1.0.0 is not present on the master branch. Therefore it is not possible to create a new version v1.0.1 on the master branch as v1.0.0 already contains a commit, which would not be present in v1.0.1.

I think the best approach would be to merge the release branch back into the master so that the master also contains the v1.0.0 commit.

In our projects we don't have a release branch, but instead create release tags directly on the master.

[qvistgaard]

@PSanetra I agree with you on that, and that is what we are doing today. But it has a couple of drawbacks:

• If someone commits while the build is running, the build will not complete because we need to pull before we can push the changes
• We need to rebase after each build
• The log will be littered with ci commits