Tag selector #141
Tag selector #141
Conversation
…iple tags on a commit. Defaults back to selecting the last tag found in the list of tags returned from git, same behavior as before, i.e. when there were no list and the tag for a commit was overwritten.
| .inject([:], { map, entry -> | ||
| if (map[entry.commit.id] == null) { | ||
| map[entry.commit.id] = [] as List<String> | ||
| } |
There was a problem hiding this comment.
Dealing with non existing values of map can be simplified by using [:].withDefault {p -> []}
There was a problem hiding this comment.
I looked for something similar, but didn't find one, thanks!
That would break the null-check later on though, but it can be changed to a simple conditional if (map[id]) break;
|
Great stuff, thanks! Could you squash the commits before merge? |
|
I think it can be done during merge? https://github.com/blog/2141-squash-your-commits I'm not sure if I can do it now that the commits are pushed already? |
|
Good call, didn't have a chance to try out this new Github Merging stuff :) Thanks once again. |
|
Great, thank you! |
|
BTW i never release the version - now it's here: 1.3.5. Sorry it took so long :) |
|
Total groovy/gradle newbie here. How do you go about telling the tagSelector option to go for the default setting which is to take the tag without the 'rc' identifier? |
|
@dafelipe130 what do you mean by this? There are usually no |
|
Basically, I'm facing the same situation described here #139 |
|
I fiddled around a bit on this one and have settled with just configuring the tagSelector to always get the first item in the tags object However, this doesn't respect the next version marker tag if its situated in the same commit as a release/pre-release tag. The next version marker tag is not handled differently anymore and is treated as any other tag contrary to what is specified here. This results in a scenario wherein axion reports the current version as the incremented version of the immediate release tag instead of the version specified by the next version marker. I suppose I can add a condition to check if the last tagged commit has a next version marker then abstain the plugin from using the tagSelector option to honor said marker. Or just instruct users to first commit something then apply the marker. Please feel free to chime in if I'm missing anything here. |
|
After analysing what you said I think bringing in |
|
I think i figured out some basic rules of better implementation. Current messy implementation stems from not wanting to interact with Git more than absolutely necessary, but i think that it only made the code hacky aka clever thus unmaintainable in the long run. Stay tuned :) |
|
So after some time i finally managed to refactor all the code that will make the "many tags" problem go away. The tests are green, but i want to add more integration tests to the mix. The branch is here: https://github.com/allegro/axion-release-plugin/tree/fix-tag-ordering The main highlight is reading all tags on commit and choosing the one with the highest version. Currently there is no way to customise the behaviour and i'm not really sure it's needed - should be no problem to add it though. After finishing work it will be released as 1.5.0, due to small API change in two places which are probably used rather rarely - custom deserializers. |
|
By |
Added support for a "tagSelector" closure in tag configuration, which is called to select among multiple tags on the same commit. Defaults back to selecting the last tag in the list of tags returned from scm (same behaviour as before). This allows to resolve #139 (see also discussion in #135).