[feat] Implementing new release process

[phoinixgrr]

Summary

Streamlining the release process for mattermost-plugins by integrating release and signing pipelines under the delivery platform.

This update automates signing and releasing by simply pushing a semver tag(e.g: v0.0.1) or by using the newly introduced Makefile targets.

make patch
make minor
make major

For Release Candidades(RC):

make patch-rc
make minor-rc
make major-rc

Ticket Link

https://mattermost.atlassian.net/browse/CLD-7848

[lieut-data]

Thanks @phoinixgrr! The changes made to streamline this pipeline are FANTASTIC.

My feedback below relates specifically to the changes to the Makefile and README.md. I'm wondering if we can simplify this and avoid lots of new "things we have to keep up to date".

[lieut-data]

nit: This isn't "useful" for most users landing on README.md who won't be triggering a release. Could we perhaps document this on https://developers.mattermost.com/ and link out instead?

[phoinixgrr]

Thank you @lieut-data,

I personally prefer having all crucial project-related data concise in the README file.

Moreover, the actual templating for new plugins includes release instructions. We iterate over those here:
https://github.com/mattermost/mattermost-plugin-starter-template/blob/master/README.md?plain=1#L113-L120

I don't have a strong opinion on this since it is mostly out of the scope of our work. Our main goal is to reach a consensus on pushing tags for release, thereby streamlining our process.

Let me know if you would like the documentation-related changes to be dropped.

[lieut-data]

That this is automated is super cool, but I'm wondering if we can avoid patching all our Makefiles everywhere like this? (It's one more thing to maintain across N repos whenever something changes.)

Instead, might we adopt the pattern used for the Tag Public Module action on the monorepo? https://github.com/mattermost/mattermost/actions/workflows/tag-public-module.yaml

Presumably this can be more centrally managed.

[phoinixgrr]

My personal preference is to use the console over the GUI whenever possible, and I recommend this approach here. This is also the practice our team follows.

Similar to my previous comment, I don't have a strong opinion on this since pushing a tag in a repository is mostly outside the scope of our work. Our main goal is to reach a consensus on pushing tags for release, thereby streamlining our process.

We don't want to strictly control how this is done. It can be done via the GUI, manually from the console, automated and calculated via a Makefile target, or by whatever method is most convenient for a team.

Makefile Patching is allready performed :) :
pr-mattermost-plugin-starter-template-200
pr-mattermost-plugin-ai-197
pr-mattermost-plugin-apps-487
pr-mattermost-plugin-bulk-invite-34
pr-mattermost-plugin-calls-765
pr-mattermost-plugin-cloud-157
pr-mattermost-plugin-community-32
pr-mattermost-plugin-demo-177
pr-mattermost-plugin-github-786
pr-mattermost-plugin-gitlab-497
pr-mattermost-plugin-google-calendar-80
pr-mattermost-plugin-jira-1083
pr-mattermost-plugin-metrics-28
pr-mattermost-plugin-msteams-689
pr-mattermost-plugin-nps-112
pr-mattermost-plugin-playbooks-1913
pr-mattermost-plugin-servicenow-195
pr-mattermost-plugin-zoom-379

[lieut-data]

Thanks, @phoinixgrr! I'll reply over at https://community.mattermost.com/core/pl/ejz7p7zizbg4dpa73u8i9kdoie so centralize the conversation and loop in @mickmister and others for feedback. Appreciate the context and support in achieving all this!!

[phoinixgrr]

@lieut-data Any objections merging this as is ?

[saturninoabril]

Thanks @lieut-data and @phoinixgrr for bringing the discussion more widely in channel, and glad to read you reached a consensus to move forward with the approach taken here by Akis.

[saturninoabril]

Thanks @lieut-data and @phoinixgrr for bringing the discussion more widely in channel, and glad to read you reached a consensus to move forward with the approach taken here by Akis.