-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#325 #314 Enable multi-module project lib dependency incrementing. #326
base: main
Are you sure you want to change the base?
#325 #314 Enable multi-module project lib dependency incrementing. #326
Conversation
Coveralls seems to be complaining about lack of tests in |
I have found that when there are large numbers of submodules (50+) and Gradle builds in parallel, the creation of the release tags causes contention on the Git repo and some of these then randomly fail without an error message. The release tag is then rolled back and the push command then fails because the object ID of the commits no longer exists. The exception that is caused looks like:
The solution is for the release tasks to be run non-concurrently and this is achieved by having all release tasks declare a common directory as a task output. Gradle ensures that only one release task executes at any one time. Whilst it would theoretically be possible to use |
5bfb848
to
48ce606
Compare
Was this ever merged in ? |
@TabraizChel nope, as you see this branch is a bit stale and with conflicts |
Is there any other way to accomplish a similar functionality to this using the Axion plugin? @john-tipper or @bgalek Or perhaps even changing where Axion detects changes for the release? |
I am not sure I understood everything here perfectly, I will share my use case & proposal and see if it fits, |
Fixes #325 and #314: enables modules dependent on other submodules to have their version incremented, even if there are no code changes in that module.
There were two issues with the plugin when it handled multi-module projects:
This PR fixes these issues in a non-breaking manner.
The PR adds 2 additional top-level tasks,
createRelaseDependents
andreleaseDependents
, which are analogous tocreateRelease
andrelease
respectively. For the purposes of this PR description,releaseDependents
will be used, butcreateReleaseDependents
operates in a similar manner. The purpose ofreleaseDependents
is to create a release for a module that has changed and also for all modules that rely on that module, and for this change to then be transitively cascaded down the dependency tree.The current
release
mechanism is idempotent and this is a very nice feature and must be retained. CallingreleaseDependents
repeatedly should not cause multiple releases to be generated.The
releaseDependents
task operates in an identical fashion to Gradle's Java plugin, which addsbuildNeeded
andbuildDependents
tasks, as described here. Within each project, therelease
task is added as a dependency ofreleaseDependents
, and that project'sreleaseDependents
task is added as a dependency of all downstream projects. CallingreleaseDependents
will thus causerelease
to be called in all downstream dependent projects.In order to actually cause the release to be created, it is necessary for the
release
task to take account of whether upstream releases were created. The plugin adds a task calledconfigureReleaseTasksTask
that is set as a dependency ofreleaseDependents
and to run prior torelease
. CallingreleaseDependents
will thus cause the following execution order:configureReleaseTasksTask
,release
,releaseDependents
. This task checks upstream tasks of the same name and determines if they released a new release by looking at anext
property on that task. If any upstream task caused a release then the task will configure therelease
task to create a version.We don't want a user to be able to mess up the idempotency of the release process through poor config, so there is a property within
VersionProperties
that determines whether a version should be force incremented (it is not parsed from config). That property is set based on a flag in theReleaseTask
that is set by theconfigureReleaseTasksTask
that runs before it.If a project has changes then the normal release process will be followed. If there are no changes then a release is created if the force increment flag is set. In this case, the new release tag is written to the last commit that relates to that project, which is not necessarily HEAD. This ensures that the version resolution for these projects is correct as they are set up to ignore changes in directories that are not related to the project in question.
Here is an example of one of the
MultiModuleProjectDependencyIntegrationTest
unit tests showing where release tags are placed using this new process: