Add dependency dirs for monorepo config

[shashken]

Add the option to configure several dependency directories to affect the version in a monorepo project

[shashken]

@bgalek WDYT

[shashken]

Adding a comment I added in #326 to provide some background:

We are moving away to use composite build, as a result when a dependency project gets updated, the main project stays on the same version, this created all sorts of problems for us so we reverted, I opened a new PR #647 that is actually continuing the work I did in #422 to make monorepos work (closed #332)
They idea is to look for latest tag in both project dir and dependency dirs and to check for diff in commits in the deps dir as well
This allows a more direct (composite build) dependency mechanism in monorepos and can help with some use cases

[shashken]

@bgalek WDYT?

[shashken]

@bgalek please let me know what you think :)
We really need this feature to be able to work with gradle composite build

[bgalek]

@shashken ok, lets do it, could you just rebase this PR?

[bgalek]

@shashken https:/allegro/axion-release-plugin/actions/runs/6183866024/job/16786446050?pr=647

[shashken]

thanks! @bgalek working on it, we are also currently working with java 8 on a single project, is it possible to release this for older java version as well as a hotfix? I saw that latest versions removed support for older java versions

[bgalek]

@shashken we could backport, but I really don't like the idea, jdk8 is dead to me ;)

[shashken]

lol @bgalek as it should be 😄 but sadly not for us just yet 😢
I can handle the backport, can you point me out to the proper flow I need to make for it here?

[codecov-commenter]

Codecov Report

Merging #647 (9ff7f87) into main (028a0f8) will decrease coverage by 0.28%.
Report is 4 commits behind head on main.
The diff coverage is 33.33%.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

@@             Coverage Diff              @@
##               main     #647      +/-   ##
============================================
- Coverage     60.74%   60.46%   -0.28%     
  Complexity      387      387              
============================================
  Files            81       81              
  Lines          1531     1538       +7     
  Branches        143      146       +3     
============================================
  Hits            930      930              
- Misses          532      537       +5     
- Partials         69       71       +2     

Files Changed	Coverage Δ
...xion/release/infrastructure/DummyRepository.groovy	24.24% <ø> (ø)
...axion/release/infrastructure/NoOpRepository.groovy	50.00% <ø> (ø)
...ech/build/axion/release/domain/MonorepoConfig.java	12.50% <0.00%> (-4.17%)	⬇️
...ch/build/axion/release/domain/VersionResolver.java	91.30% <25.00%> (-6.38%)	⬇️
...xion/release/infrastructure/git/GitRepository.java	73.75% <50.00%> (-0.62%)	⬇️

[bgalek]

lol @bgalek as it should be 😄 but sadly not for us just yet 😢 I can handle the backport, can you point me out to the proper flow I need to make for it here?

I would recommend a fork then, I don't want to manage two versions at the same time (v2), and this is a new feature not fixing a bug, sorry

[shashken]

Ok so this one is ready from my side
Do you think it will be possible to release a hotfix on this repo for 1.14.x?
It will be a bit challenging building a pipeline on our side just for 1 version
Will it be simple in this repo?

[bgalek]

thank you for understanding and your collaboration!
It should be very basic - if you're sticking to 1.14.x you could make the change locally and update the resulting jar to your maven without any pipelines (YAGNI) - assuming that you will migrate to 1.15.x and get back to main upstream someday ;)

[bgalek]

@shashken please also upadate documentation

[shashken]

@bgalek Added

[bgalek]

@shashken nice!
Last thing, could you add at least one test using monorepos settings?
also I think we could use "monorepo" instead of plural version

[shashken]

@bgalek added a test, this branch was opened 1.5 months ago, I am loosing a lot of context here, lets aim for short living branches and move the rename to a different issue/PR
WDYT?

[bgalek]

Sure, we can