Automating create a new release when develop merged to main

[Abelarm]

This new workflow tries to solve the #439. It automatically bump the tag version with a patch v0.0.1 -> v0.0.2 and generate the release for that version every time something is pushed to main.

It uses the custom action:

anothrNick/github-tag-action

NOTE

So we can manage the version by using
#major , #minor , #patch or by tagging the HEAD

I already tried on my fork, on a different branch

[jack89roberts]

That's great, thanks @Abelarm ! I wonder if there's a way we can automate changing the value of __version__ in airsenal/__init__.py as well? If you haven't seen a way to do that I'm happy to merge this as the first step, though, should already make our lives a bit easier!

[Abelarm]

I’ll give it a look!

[Abelarm]

I have searched a bit around and there are no automatic actions to change the version inside __init__.py.
One solution would be something like this: src-d/lookout-sdk#2 (comment)
which generated a .version file from which the __init__ would read... I am not a big fan of this.

Btw since you already need to push to master to trigger the even, the last commit you do before the changing would be the version bump depending of the type of commit you are going to do #major, #minor , #patch

[jack89roberts]

Thanks for looking! My main thought is we should try to have guarantees that the GitHub release and __init__ versions stay in sync. I've marked this as hacktoberfest-accepted (so that should get picked up for you if you're doing Hacktoberfest), but I'll think about this/discuss it with the other maintainers before merging.

[Abelarm]

Thank you for the tag 👍

Yeah I agree with you, too much automation could lead to disasters!
I would suggest to test this action on another-branch using the tag prerelease (everything is documented in the repo I have posted) and if benefits are more than the drawbacks move to the main.

Btw was a funny PR I learned a lot :)