-Prelease.overriddenBranchName=xxx is ignored

[ddeath]

When publishing with ./gradlew publish -Prelease.overriddenBranchName="breaking/asd" overriddenBranchName parameter is ignored. This is happening in github when we want to publish from main branch.
This is because of this line:

axion-release-plugin/src/main/java/pl/allegro/tech/build/axion/release/infrastructure/git/GitRepository.java

Line 390 in 48ba8e1

if ("HEAD".equals(branchName) && properties.getOverriddenBranchName() != null && !properties.getOverriddenBranchName().isEmpty()) {

in other words overriddenBranchName is only considered if we are in detached state.

We want to use it on main branch since we are releasing after merge. But that means that branch versioning does not work because it will always be main branch. So idea was to use overriddenBranchName but that does not work either...

[bgalek]

hi!
I would use unshallowing + releaseBranchNames feature.

enable it by:

scmVersion {
    unshallowRepoOnCI.set(true)
}

With this setup, ./gradlew release will do release main or master (it's configurable) branch names, others will result with snapshots.

[ddeath]

I dont see how it would help in my scenario. I tried to used unshallowRepoOnCI but it has no effect.

axion-release-plugin does not have access to original branch name if it is running on main branch. That is why I want to use overriddenBranchName feature.

"workaround" for this is to use:

  - uses: actions/checkout@v4
        with:
          fetch-depth: 0
          ref: ${{ github.sha }}

With that overriddenBranchName will work because above code will switch git to "Detached" mode aka "HEAD" at least that is my understanding of what is happening

[ddeath]

Maybe to make it even more clear. Here is our setup:

scmVersion {
    repository {
        directory = "${layout.projectDirectory}/../.."
    }
    tag {
        prefix.set("chewy-steak-service-")
    }
    versionCreator("simple")
    snapshotCreator { _, _ -> "" }
    branchVersionIncrementer.putAll(
        mapOf(
            "breaking/.*" to "incrementMajor",
            "feature/.*" to "incrementMinor",
            "fix/.*" to "incrementPatch",
            "bugfix/.*" to "incrementPatch",
        ),
    )
}

If I create PR where I want to merge branch breaking/NOJIRA/testing into main then If we run ./gradlew publish on main branch after merge, it will NOT increment major version and also that overriddenBranchName does not work until we apply "workaround" specified in previous post

[bgalek]

axion release plugin actually integrates with github,
fetch-depth: 0 and ref: ${{ github.sha }} is not needed anymore in github actions environment

[bgalek]

assiming: releaseOnlyOnReleaseBranches.set(true) and unshallowRepoOnCI.set(true)
example workflow:

name: Service Release

on:
  pull_request:
  push:
    branches:
      - main
jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      released-version: ${{ steps.release.outputs.released-version }} # optional if you want to log it or smth
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: '23'
          distribution: 'temurin'
      - uses: gradle/actions/setup-gradle@v4
      - run: ./gradlew build
      - run: ./gradlew release
        id: release
      - run: ./gradlew publish

name: Library Release

on:
  release:
    types: [ created ]

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: '23'
          distribution: 'temurin'
      - uses: gradle/actions/setup-gradle@v4
      - run: ./gradlew publish

would work out-of-the-box

[ddeath]

It does not work like that. I used your workflow and it is not bumping version as I would expect.

So I created this PR:

With setting like this:

And result bumped patch version anyway.... I am expecting version 1.0.0 instead I got 0.1.1

I created testing repo where you can inspect it: https://github.com/ddeath/test-axion-release

[bgalek]

okay, it's probably a problem with the branchVersionIncrementer feature; I would need to check that out - maybe it's trying to resolve the branch before unshallowing...
It could also be "simple" version creator that strips branch name... could you try: commenting out versionCreator setting -> rerun?
If it won't work we would need to review branchVersionIncrementer implementation

BTW. It looks like application workflow not a library one, if you still want to stick with semver there I would recommend moving to github releases, so you can have release notes (for people but also for dependabot), automated labels and breaking change detection - instead of branchname requirements.

[ddeath]

I think it is just no supported. Because again when merge happens on main branch then branch name will be resolved to main. Afaik there is no information about source branch name in github context.
The only way how to retrieve that is to call Github API to get list of associated PRs: https://docs.github.com/en/rest/commits/commits?apiVersion=2022-11-28#list-pull-requests-associated-with-a-commit.

As for github releases, do you have something specific in mind? We are releasing automatically on each merge to main branch and we have monorepo where we have multiple applications there.

[bgalek]

ah, right - I'm trying to wrap my head around your workflow ;)
branchVersionIncrementer won't be able to work in your case.

For monorepository with multiple applications (not modules/libraries) I assume you want to have multiple different versions.
I worked with such repos using axion-release-plugin and github releases without any problems.

My recommendation:

Assuming a repository that consists of dirs:

• app1/
• app2/
• app3/

In your repository, you should have multiple tags:

app1-v1.0.0
app2-v2.0.0
app3-v3.0.0

If you want to release app2-v2.1.0:

• You create a PR with changes
• You marge those changes (nothing happened yet)
• You create a GitHub Release https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository, you need to provide version manually v.2.1.0 (since you need to decide is it breaking or not, and ofc create release notes about what was changed)
• You need to have one, global pre/post release workflow, that will use axion-release-plugin to release app2 with given tag (release created git tag step before).
• next you can publish your app release jar/war/distzip that will have proper version (v.2.1.0)
• and then deploy if you need ;)

I'm writing this on the fly, sorry if it's too chaotic - I hope you get the idea.
If you need more clarification I can prepare more detailed guide or show you such project to share with you how it works.

[ddeath]

Yeah and that comes back to the original issue. Because we are on main branch we would like to use overriddenBranchName so branchVersionIncrementer works.

as a workaround:

  - uses: actions/checkout@v4
        with:
          fetch-depth: 0
          ref: ${{ github.sha }}

That works but imho overriddenBranchName is little bit confusing because it does not override the branch name unless we are in detached HEAD state.

[ddeath]

And just to complete the picture. Our workflow is:

1. create PR with your new feature
2. merge PR to main
3. workflow on main branch is triggered by push commit to it (from merge)
   a. build app
   b. release app (push tags)
   c. publish docker images
   d. automatically deploy

So after PR is merged, there is no human intervention and it gets deployed.

[bgalek]

I'm glad you found a workaround.
overriddenBranchName is one of features that I think we could get rid of in v2 version - as you said it's confusing ;)
Can you live with the workaround you come up with or do you want to make a contribution to support overriding branch names not only in detached HEAD state?

[ddeath]

I am fine with creating PR for it if you want to have such change.

If you do, I see two possible aproaches:

1. Remove check for HEAD state - this is potentially breaking / unexpected change for users of this library
2. Add new flag something like forceBranchOverride=true

Let me know if you want it. I am kind of ok-ish to live with the workaround but I would rather not have it 😄

[bgalek]

To answer that i would need to dig into git blame/history to see what was the point of this state check.
Maybe it was a security measure not to allow branchOverride when checked out on tag (or other ref)...

[ddeath]

Sure. But kind of does not matter what the original reason was. There will be always people who use it on main branch and they did not noticed that it is doing nothing 😄 so if we "fix" it, it wont be fix for them 😄

[bgalek]

True, I just want to do everything I can to understand the decision to add HEAD check there :P
You can proceed with the PR (removing HEAD check), hopefully it will be an easy one. In the meantime I'll try to dig into it