push tag even if no changes are detected in Multi-repo project

[neilyalowitz]

I'm attempting to release using a multi-module project but I notice the default behavior prevents "re-tagging" a release. We're using a "release train" where upon release all modules are given the same version number. This means some modules which rarely (or never) change should still be tagged with each new release. Example: current version is 1.0.0, new code is committed to a module, when ready to release then all modules need to be tagged to 1.0.1 regardless if there are any code changes in each module repository. Default behavior gives a warning message "nothing to release".

logger.quiet("Working on released version ${version}, nothing to release")

Does this "force release" functionality already exist? I tested a small code change in the Axion plugin to make this work but I am wondering if there is a cleaner way to do this.

Thanks,
Neil

[adamdubiel]

Would you mind showing the example directory structure, highlighting modules and how you configure axion in build.gradle? Is it per module configuration or global one?

Technically axion is now ready to handle such situations (multiple tags on single commit) when resolving versions but i would like to understand how it behaves when you create release.

[neilyalowitz]

I'm using a directory structure with a global configuration following the documentation examples. Axion almost worked for this use case but it did require some small changes. The changes enable the user to pass command line flags to skip certain Axion verification steps. This allows tagging to proceed when a) module is on HEAD and when b) there is no snapshot detected (those conditions would normally cause the release to fail).

With those cases handled I am able to run a release in the root module regardless of changes to modules... ie-- permits the user to run a release on each module even if there are no committed changes. Example with the flags added (see patch file below):

./gradlew release -Prelease.allModules -Prelease.allowNextVersionOnHead=true

I also needed to release all modules with the same version string. There wasn't an obvious way to accomplish this so I coded two allprojects loops in build.gradle; the first loop to examine all modules and collect the highest version found and the second loop to set each module version to the value we found.

build.gradle

scmVersion {
  //...
}

//iterate through allprojects and find the highest version
allprojects {
    if (it.scmVersion?.version > rootProject.ext.highestVersion.version) {
        rootProject.ext.highestVersion = it.scmVersion
    }
}

//iterate through allprojects again and set each project version with the highest version discovered
allprojects {
    it.version = rootProject.ext.highestVersion.version
}

Example before code changes:

moduleA => v1.1.0
moduleB => v1.1.0
moduleC => v1.1.0

Example after code changes are committed to B:

moduleA => v1.1.0
moduleB => v1.1.1-SNAPSHOT
moduleC => v1.1.0

Example after release:

moduleA => v1.1.1
moduleB => v1.1.1
moduleC => v1.1.1

Here is a dirty patch file with the changes to meet this use case. I think this "single release version" feature is valuable for tagging large multi-module frameworks. With the small patch attached I was able to use Axion for this process.

patch-axion-support-multirepo-release.txt

Also... excuse me for the delayed response and thanks for the feedback!

[adamdubiel]

I think I'm missing something to understand what you want to achieve. What I don't understand is why do you need separate versions per module. Maybe you can have single version for the project?

To better illustrate what I mean and how I see your project based on info you gave:

build.gradle
moduleA -> version A
moduleB -> version B
moduleC -> version C

Since you keep versions in sync on every release, the structure looks probably bit more like:

build.gradle
moduleA -> 1.1.0-SNPASHOT (version A)
moduleB -> 1.0.0 (version B)
moduleC -> 1.1.0-SNAPSHOT (version C)

Or in case of some next-version manoeuvres:

build.gradle
moduleA -> 1.1.0-SNPASHOT (version A)
moduleB -> 1.0.0 (version B)
moduleC -> 1.2.0-SNAPSHOT (version C)

What you want to get after release is:

build.gradle
moduleA -> 1.2.0 (previous: 1.1.0-SNAPSHOT) (version A)
moduleB -> 1.2.0 (previous: 1.0.0) (version B)
moduleC -> 1.2.0 (previous: 1.2.0-SNAPSHOT) (version C)

So why have separate versioning per module? Why not keep it simple and have one version for all?

build.gradle -> 1.2.0
moduleA
moduleB
moduleC

[neilyalowitz]

Sorry, let me correct the example layout. For my case there is a root project module which contains multiple submodules. For most releases the root project module does not need to change.

build.gradle
myRootProject
    build.gradle
    moduleA
    --
    build.gradle
    moduleB
    --
    build.gradle
    moduleC
    --
    ...etc

We considered a workaround similar to your suggestion... when we wanted to release, we could commit a change to myRootProject and apply that version to all subprojects. However this process wasn't attractive because it would require unnecessary commits to myRootProject (or Axion would abort the release task). The goal is to increment version in an automated way if either root project or submodules have changes ready to release. I couldn't make that work without the patch changes above.

EDIT: This isn't an active issue, closing it now.