Support Mono Repo

[tobad357]

Currently we have a mono repo with multiple gradle sub projects
Each subproject has different versions which works fine with separate semantic-build-versioning.gradle files and using tagPrefix/tagPattern

The only issue we have is that any commit / change across the whole git repo
will cause a new version to be created/allowed for the subproject when what
would be better is to only check for commits/changes that affects files in the subproject directory and potentially some other folders.

Is this functionality something you could see the plugin to support?

[vivin]

When you say "any commit/change across the whole git repo", what sort of change do you mean? Can you given an example? I'm having a little trouble understanding why such a change wouldn't affect any of the subprojects; aren't they all part of the same repo?

Do you mean that even when you make a change in one subproject, the plugin still calculates versions for all subprojects?

I've actually run into this scenario and my workaround was to write a script (I used perl) that identified the subprojects that changed and then explicitly build them. For example, if the script identified that subproject1 and subproject3 were the ones that actually changed, it would construct a command line gradle :subproject1:build :subproject3:build ensuring that only those two were built.

[tobad357]

The goal is to have completely separate versions for subprojects in the same repo so that when the CI system builds it will skip building the projects which don't have any changes, gradle already does all the incremental builds and won't build unchanged items due to buildcache so now just need to sort the versioning to make sure no new jars get created

This means we only want to create a new prerelease version/version if files under the subprojects and potentially some other key files/directory have been touched, not if we touch under a different subproject

Example

| .git/
| build.gradle
| -- subproject1
| ---- semantic-build-versioning.gradle
|      src/Main1.java
| -- subproject2
| ---- semantic-build-versioning.gradle
|      src/Main2.java

1. gradle :subproject1:tag -Prelease=true -PbumpMinor=true -> now version 1.0.1
2. gradle :subproject2:tag -Prelease=true -PbumpMinor=true -> now version 2.0.2
3. gradle :subproject1:printVersion -> 1.0.1
4. gradle :subproject2:printVersion -> 2.0.2
5. Edit subproject1/src/Main1.java
6. gradle :subproject1:printVersion -> 1.0.2-SNAPSHOT
7. gradle :subproject2:printVersion -> 2.0.3-SNAPSHOT

For us we would want gradle :subproject2:printVersion to stay at 2.0.2 as no changes have been made to files affecting subproject2

If possible there could be a property in semantic-build-versioning.gradle where we could pass in paths which tell the plugin which directories to check

paths = ["subproject1/**","build.gradle","etc/conf.properties"]

Or maybe use gradle to detect if the project has changed

[vivin]

Ah, I understand now. I think this could actually be done similar to task inputs and outputs perhaps. I wonder if there is a way to hook into that through the gradle API.

[tobad357]

For us I think it would be better to check if the commits since the last version touches any of the configured paths. The problem relying on gradle would be that the cache may be cleared and then an unnecessary version bump will happen

[vivin]

@tobad357 Good point. Instead of explicitly providing paths, though I think it might be better to see if any of the changed files are from the subproject's directory when deciding whether to bump the version.

[tobad357]

@vivin I actually hacked this feature into a local version of the plugin
At the same time we made the customizations for branch name on snapshot builds

Let me see if I have time this weekend to clean it up and I can see if I can share

The reason we use includePaths is that sometimes there is a file that affects the build outside of the subproject (there shouldn't be....), this allows us to support that
Maybe the subproject dir should be the default

[tobad357]

FYI we also added a flag to allow tag task to disregard if the tag already exists
This way we can run tag -Prelease --ignoreDuplicateTags --push and it will only tag and push for subprojects that have been updated

[larcos01]

This issue seems to have stalled. Did this functionality ever make it into the product?