Add tools for releasing the Devfile schema

[johnmcollier]

What does this PR do?

This PR adds tools for releasing and publishing the Devfile schema, as outlined here:

• Adds a script to run that generates the schemas for the version being released (e.g. 2.0.0, 2.1.0, etc), and opens a pull request to merge them to the release branch.
  • Script is based on the make-release.sh from https://github.com/che-incubator/chectl/blob/master/make-release.sh
• Adds a GitHub workflow action that publishes the released schemas to the Devfile website when a release is created on GitHub.
  • For the time being, the GitHub release still needs to be manually created at first after merging the release PR to trigger the workflow.

What issues does this PR fix or reference?

Resolves #150

Is your PR tested? Consider putting some instruction how to test your changes

Yes.

For the make-release.sh script:

1. Ensure the hub CLI is installed and the GITHUB_TOKEN environment variable is set in your shell
2. Copy the script over from this PR to your fork of the repo
3. Run ./make-release.sh <some-schema-version> v1alpha2

For the GitHub action, see https://github.com/johnmcollier/api/runs/1558896668?check_suite_focus=true for what a sample run looks like.

Docs PR

N/A

[davidfestal]

Nothing more to comment than what @amisevsk pointed out.

As a side note, I'm just wondering what happens on the master branch after a release of the schemas (that happens in the release branch afaict). Is it bumped to the next alpha version that follows the last release version, or something like that ?
Do we want to define a process here as well ?

[johnmcollier]

As a side note, I'm just wondering what happens on the master branch after a release of the schemas (that happens in the release branch afaict). Is it bumped to the next alpha version that follows the last release version, or something like that ?
Do we want to define a process here as well ?

@davidfestal That's a good point, I think we've got a couple options here?

1. Keep master hardcoded to something like next( or nightly, etc) and only increment/set the version on the release branch
2. Or have the make-release.sh also open a PR on master that bumps the schema version to the next minor version with a -alpha appended (e.g. 2.1.0-alpha)

WDYT?

[johnmcollier]

I've updated this to include additional steps that opens a PR to bump the schema version on master (with a -alpha appended)

CC @davidfestal @elsony

[elsony]

This script automatically promotes the new version to stable and updating the minor version on the master branch. This script currently should be only be used on promoting code from master to a newer version. This may be sufficient for the time being but in case we need to do a service release on older versions and tries to run this script, we may end up moving stable to an earlier release. In order to avoid this potential problem, I wonder if we should:

1. add an extra check on the new version that we are trying to declare to make sure it is a version later than the existing stable.
2. if the new version that we try to set to is an earlier version than stable, we should probably prompt a warning as part of the script and saying we are trying to declare a release older than the existing stable release. The user can confirm it when running the script and it won't trigger the promotion to the stable nor updating the minor version on the master.

[johnmcollier]

@elsony Thanks for your review comments. I've updated the PR with the following changes:

• (release-schema.yml) Don't publish schema to stable if stable has a never version than what's being published
• (make-release.sh) Don't update master schema version if the master version is newer than what's being published
• Update design doc to clearly state that a Github token is required to run the script
• Clean up the release script for some clarity

[elsony]

/lgtm

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: amisevsk, davidfestal, elsony, johnmcollier
To complete the pull request process, please assign after the PR has been reviewed.
You can assign the PR to them by writing /assign in a comment when ready.

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

Details

Needs approval from an approver in each of these files:

• OWNERS

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