WIP: Version pinning

[realdadfish]

Implement version pinning in Axion (closes #328)

TODO:

• Missing unit tests for VersionService
• More integration tests
• Documentation

[realdadfish]

Updated to recent Axion master.

[bgalek]

@realdadfish please also update docs

[realdadfish]

@bgalek Will do, if this PR actually has a chance of getting merged :)

Would you please make a code review before, so in case some things change (e.g. the enable flag should be removed, the default filename should be changed, ...) I don't document things twice. Thanks!

[bgalek]

@realdadfish I like to start review from the docs, because than I can focus on developers experience and necessary migrations - then I'm prepared to review code with that already in mind ;)

[bgalek]

but I understand what you are saying, I'll try to review it next week

[realdadfish]

@bgalek Friendly reminder :)

[bgalek]

@realdadfish I'm not really comfortable with this plugin writing and reading files from the filesystem. That should be externalized - if somebody wants to use a DB, git-specific-feature, or anything like that.

Can't some kind of hooks solve your use case? STAGE1 - onNewRealese(context) hook which you can extract the version from and save it wherever you like (you decide if it is a file, a DB or maybe your pipeline metadata storage) STAGE2 - beforeRelease() hook, that you implement to check if version should be updated from outside and tagged again before going to the next stage

This way would be more "generic" than pinning feature. WDYT?

[realdadfish]

Hooks would be fine for me, as they'd basically allow the same functionality, but if serialization is externalized, I think one does not need any adaptions in the main plugin itself anymore. One could simply wrap this plugin into a "meta-version" plugin, call "createRelease", save the output of "currentVersion" into version.txt, and use that as version onwards in the project as long as the file exists. Finally, one would call "release" in the very last stage (verifying that the "release" is identical to what is in version.txt) and push the result.

I think during the discussion it became clear that the adaptions are too big of a hurdle to be integrated in the main source, so I'll close this PR and ticket, continueing to work with my local fork of it. If the maintenance of that fork becomes unbearable for me, I'll probably just go back to vanilla and make a workaround like the one discussed earlier.