Add gh action workflow for creating releases

[CrafterPika]

Title says all. commits with the pattern (S)(s)upport (X.X)/(R)(r)elease (blah) will trigger a workflow that creates an release with the setup zip and the jar.

for PRs i haven't really looked how to make that work, and i won't do it today it's 1:40 AM now, and i need some sleep.

will demo the workflow tomorrow.

if you have any suggestions tell me.

[CrafterPika]

Here's the demo how it looks

also made that the regex pattern looks at any point of the head commit message so it’s possible to do add feature X and bump version

[Pugmatt]

Thanks for working on this, looks great, and should make releases a lot smoother process. I don't believe checking the PRs itself will actually be needed if it checks the latest commit like you have setup now, so it's probably good as is. Better doing it this way probably since it will begin the release after a PR is actually merged by noticing it in the latest commit.

[CrafterPika]

well then i guess the PR is ready to merge.

[kmpoppe]

@CrafterPika it seems me creating a merge just for updating the supported version and then merging it created two new releases. Did I overlook something?

[Pugmatt]

I deleted the two releases, but can still be seen under tags for reference https://github.com/Pugmatt/BedrockConnect/tags

Also thinking we can probably removed "Support" from the trigger words, since we'll be updating supportedVersion sometimes without necessarily needing a new release, since I'm guessing it just saw "support" in supportedVersion and triggered the release.

[kmpoppe]

Also thinking we can probably removed "Support" from the trigger words, since we'll be updating supportedVersion sometimes without necessarily needing a new release, since I'm guessing it just saw "support" in supportedVersion and triggered the release.

That sounds like a reason. Good spot!

Also @Pugmatt, you can delete tags using the Git Bash as described here, I can't do that because I only got my fork checked out. https://devconnected.com/how-to-delete-local-and-remote-tags-on-git/

[CrafterPika]

Also thinking we can probably removed "Support" from the trigger words, since we'll be updating supportedVersion sometimes without necessarily needing a new release, since I'm guessing it just saw "support" in supportedVersion and triggered the release.

indeed, i am gonna remove it from the regex.

[CrafterPika]

actually i figured a better way ^((S|s)upport.*)|((R|r)elease.*|(B|b)ump version.*).* EDIT one to exclude supportedVersion ^((?!supportedVersion)(S|s)upport.*)|((R|r)elease.*|(B|b)ump version.*).*

now it will listen for support only at the beginning

@kmpoppe thoughts? or just remove entirely?

[CrafterPika]

well there we go ig https://github.com/Pugmatt/BedrockConnect/commit/f8ea8e43fec54805aaa8c37453cad7758288079b, now it shouldn't trigger just because "support" is in the commit message.

i prefer keeping support because mostly when supporting a new bedrock version support is written at the begin