Cannot add branchName into git tag

[rafalpiastkaroche]

Hello! We have used the plugin for some time with success, however had many issues with git tags when two developers were creating two feature branches from master and then having a build in similar time. Task 'release' fails because git tags are having the same name. Therefore, we wanted to add branch name into "tag" block, but there is no explicit option. Implementing serializer and deserializer handles the thing, however the solution is not elegant.

scmVersion {
    tag {
        prefix = 'prefix'
        versionSeparator = '-'

        serialize = { config, version ->
            if (scmPosition.branch != 'master' && scmPosition.branch != 'HEAD') {
                return prefix + versionSeparator + version + versionSeparator + scmPosition.branch
            } else {
                return prefix + versionSeparator + version
            }
        }

        deserialize = { config, position, tagName ->
            return tagName.substring(config.prefix.length() + config.versionSeparator.length())
        }
    }
    branchVersionIncrementer = [
            'master': 'incrementMinor',
            '.*'    : 'incrementPatch'
    ]
}

Would you care to create a method that adds git branchName into tag? or point me to the best class where I can create PR?

Thanks!

[bgalek]

Hi! Tags ale repository-wide no branch wide (if I understand it correctly) Why would you need to create tags for feature branches? I would suggest creating deployment tags only for main branches. Still I would like to know more about your case/pipeline.

[rafalpiastkaroche]

Yes, you are correct :) However we have master branch that has a certain version/tag, then plan in Bamboo takes this tag and creates build on AWS (based on current version) and automatically deploys on development environment.

Assuming developer A wants to create a branch from master with feature (adobe analytics) and create a build to later test on environment and developer B creates different branch in the same time (notification) and also creates a build, they will have the same version in the tag (myprefix-1.200.1). The only option to handle this, is to manually create tag with 'myprefix-1.200.2' and build again. This wouldn't be an issue if we hadn't been creating a lot of builds for feature branches starting with the same master and it's tag.

What we would like to change, is to have versioning per each branch (therefore we need to include in tag, it's name during versioning). Please find attached drawing - should be helpful:

--------------------- master.   prefix: "myprefix-"
--------- myprefix-1.200.0 ----------- master
                           \--- myprefix-1.200.1 ---- (adobe-analytics)  myprefix-api-1.200.1-adobe-analytics
                           \---- myprefix-1.200.1 ---- (notification-fix)  myprefix-api-1.200.1-notification                          
                           
                           \--- myprefix-1.200.1-adobe-analytics ---- (adobe-analytics)  myprefix-api-1.200.1-adobe-analytics
                           \---- myprefix-1.200.1-notification ---- (notification-fix)  myprefix-api-1.200.1-notification                          
                           
                           
WANTED SOLUTION: 			\--- myprefix-1.200.1-adobe-analytics ---------------- myprefix-1.200.2-adobe-analytics ------

where: myprefix-1.200.1 is a tag name (adobe-analytics) is a branch name

[bgalek]

so basically tag.suffix method should be enough, am I right? (branch name) - yet I still hate the idea ;( branch called adobe-analytics or notifications-fix is already a good commit alias why bother creating another tag? When the tag will be removed (it's unnecessary after the merge). I would checkout branch instead of tag on your CI (bamboo).

[bgalek]

and also a question, do you use axion-release-plugin when developing applications (not library)? What does it mean for an application to move from 1.0.1 to 2.0.15? Does it mean it was rewritten? Is semver applicable anyhow? How is it better than calendar-ver or sha?

[rafalpiastkaroche]

Thanks for answering @bgalek. Yes, something like tag.suffing would be ok. We have added our own serialization and deserialization with scmPosition.branch string in scmVersion.tag task to override existing solution. For an application to move from 1.0.1 to 2.0.15 means it was rewritten (we follow semver), however we operate now within minor and patch increments only. We do not use calendar-ver nor sha, because we want to keep increasing order of version and we started using axion 2yrs ago, when re there weren't much of choice at that time for gradle versioning plugins.

[spyroid]

Hi. I'm also voting for this feature - independent versions for each branch.