[Devtools] Registry-support Release Automation Script

[Jdubrick]

Description of Changes

Summarize the changes you made as part of this pull request.

This PR is responsible for adding a script for automating the release process for this repository. You can view the release process here.

With the process, the script can handle the following:

• Create tags related to releases for major, minor and patch releases
• Create release branches for previous releases (for major and minor)
  • E.g. If 2.1.0 is cut, a release/2.0.x branch will be created for previous release backports
• Create release candidate branches for tracking (if necessary)

The user will need to create the release themselves based off the pre-created tag via GitHub and that will be reflected in the release process documentation after this PR is merged.

Related Issue(s)

Link the GitHub/GitLab/JIRA issues that are related to this PR.

resolves devfile/api#1450

Acceptance Criteria

Tests

• Test Coverage
  • Are your changes sufficiently tested, and are any applicable test cases added or updated to cover your changes?

Documentation

• Does the REST API doc need to be updated with your changes?
• Does the registry library doc need to be updated with your changes?

Tests Performed

Explain what tests you personally ran to ensure the changes are functioning as expected.

How To Test

Instructions for the reviewer on how to test your changes.

Notes To Reviewer

Any notes you would like to include for the reviewer.

[thepetk]

A question I have (might not be 100% related to this PR), is if we should include the document of the release process too here. IMO it feels more complete to have the documentation with the automation together.

[Jdubrick]

A question I have (might not be 100% related to this PR), is if we should include the document of the release process too here. IMO it feels more complete to have the documentation with the automation together.

In the README you mean? I linked it in the PR so far

[thepetk]

A question I have (might not be 100% related to this PR), is if we should include the document of the release process too here. IMO it feels more complete to have the documentation with the automation together.

In the README you mean? I linked it in the PR so far

Yeah, in the main README.md I'd expect a link to a release process and there we can mention the automation script too. More or less to include the information from the link you provide in the PR. For instance, the process section is mostly about how to use the script and it might be nice to have some info about the release process itself (what branches we use the tags we use etc).

[Jdubrick]

A question I have (might not be 100% related to this PR), is if we should include the document of the release process too here. IMO it feels more complete to have the documentation with the automation together.

In the README you mean? I linked it in the PR so far

Yeah, in the main README.md I'd expect a link to a release process and there we can mention the automation script too. More or less to include the information from the link you provide in the PR. For instance, the process section is mostly about how to use the script and it might be nice to have some info about the release process itself (what branches we use the tags we use etc).

@thepetk I included in my last commit a portion linking to the process doc, I am planning on updating the google doc with script usage after this PR is merged so I can accommodate any changes made

[thepetk]

A question I have (might not be 100% related to this PR), is if we should include the document of the release process too here. IMO it feels more complete to have the documentation with the automation together.

In the README you mean? I linked it in the PR so far

Yeah, in the main README.md I'd expect a link to a release process and there we can mention the automation script too. More or less to include the information from the link you provide in the PR. For instance, the process section is mostly about how to use the script and it might be nice to have some info about the release process itself (what branches we use the tags we use etc).

@thepetk I included in my last commit a portion linking to the process doc, I am planning on updating the google doc with script usage after this PR is merged so I can accommodate any changes made

Maybe we could also think to move the google doc to the repo? WDYT?

[thepetk]

/lgtm

[Jdubrick]

A question I have (might not be 100% related to this PR), is if we should include the document of the release process too here. IMO it feels more complete to have the documentation with the automation together.

In the README you mean? I linked it in the PR so far

Yeah, in the main README.md I'd expect a link to a release process and there we can mention the automation script too. More or less to include the information from the link you provide in the PR. For instance, the process section is mostly about how to use the script and it might be nice to have some info about the release process itself (what branches we use the tags we use etc).

@thepetk I included in my last commit a portion linking to the process doc, I am planning on updating the google doc with script usage after this PR is merged so I can accommodate any changes made

Maybe we could also think to move the google doc to the repo? WDYT?

Do we do that in other devfile repos? I am on the fence since the process requires write access to the repo so it only is relevant to our team

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 41.78%. Comparing base (a6907ad) to head (b90c4d6).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #260   +/-   ##
=======================================
  Coverage   41.78%   41.78%           
=======================================
  Files           9        9           
  Lines        3269     3269           
=======================================
  Hits         1366     1366           
  Misses       1697     1697           
  Partials      206      206           

Flag	Coverage Δ
	?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[thepetk]

A question I have (might not be 100% related to this PR), is if we should include the document of the release process too here. IMO it feels more complete to have the documentation with the automation together.

In the README you mean? I linked it in the PR so far

Yeah, in the main README.md I'd expect a link to a release process and there we can mention the automation script too. More or less to include the information from the link you provide in the PR. For instance, the process section is mostly about how to use the script and it might be nice to have some info about the release process itself (what branches we use the tags we use etc).

@thepetk I included in my last commit a portion linking to the process doc, I am planning on updating the google doc with script usage after this PR is merged so I can accommodate any changes made

Maybe we could also think to move the google doc to the repo? WDYT?

Do we do that in other devfile repos? I am on the fence since the process requires write access to the repo so it only is relevant to our team

We have published a process or key points of the process for several repos:

• api
• alizer
• library

IMO is ok to add some information about the release process and remove the link to the google doc.
Regarding this case I feel the release process definition and the release automation script should go together, as the process definition epxlains the purpose of the automation script.

[Jdubrick]

@thepetk I'll port over the process doc to a .md as part of this PR, going to mark this PR as hold for now while I do that

[thepetk]

@thepetk I'll port over the process doc to a .md as part of this PR, going to mark this PR as hold for now while I do that

I think we can also address this in a different PR if this one is urgent!

[Jdubrick]

@thepetk I'll port over the process doc to a .md as part of this PR, going to mark this PR as hold for now while I do that

I think we can also address this in a different PR if this one is urgent!

I can contain it as part of this :) no worries

[Jdubrick]

@thepetk I ported the google doc release process to a markdown file, I made some tweaks to it to accommodate comments left on the google doc! Do you mind doing a re-review?

[thepetk]

@Jdubrick looks good to me. I don't know if you'd like to merge release/PROCESS.md and release/README.md in a single file called release/RELEASE.md similarly to what we have in devfile/api

[Jdubrick]

consolidate into one readme

@thepetk
I combined them into one readme in my last commit: c63f436

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Jdubrick, thepetk

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [Jdubrick,thepetk]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment