feat(automation): Add GitHub Action to handle creating a new release #484
Conversation
andyatmiami
force-pushed
the
feat/gha-create-release
branch
from
8664f65 to
e4e6cd4
Compare
This commit replaces the "placeholder" create-release.yaml file to include functionality to actually create a opendatahub-io/kubeflow release following the original manual process. The GHA can be invoked manually as a workflow from GitHub as well as invoked as part of the kubeflow-release action. `kubeflow-release.yaml` has been modified to pass in the target branch name for cutting the release. The release/tag name is **NOT** provided as the `create-release.sh` script will auto-compute what the proper tag name should be. - Please note that the tag name **can** be provided if necessary in the future... at which point the tag name would be honored as is (i.e. no "auto-incrementing" logic is performed if the tag name provided as input) `create-release.sh` will also handle auto-updating the release tag for future scenarios where we change the target branch (ex: `v1.9-branch` to `v2.0-branch`). Please see the (extensive) comments in `.github/scripts/create-release.sh` for deeper explanation on implementation. - Please note, in what may be a "controversial" decision, I have extracted the script into its own file as opposed to embedding it within the `yaml` of the action. I find it more pleasant to read/develop when the script is in its own file - and also allows code editors to be smarter in offering hints on the source. Related-to: https://issues.redhat.com/browse/RHOAIENG-15391
andyatmiami
force-pushed
the
feat/gha-create-release
branch
from
e4e6cd4 to
bf04738
Compare
|
/lgtm |
| ## Description: | ||
| ## | ||
| ## This script automates the process involved in creating a new release for the opendatahub-io/kubeflow repository as | ||
| ## documented in https://issues.redhat.com/browse/RHOAIENG-15391. |
There was a problem hiding this comment.
we can mention that for local execution the gh cli tool and GH token need to be configured on the machine
There was a problem hiding this comment.
will add this in a subsequent PR - good call to include
There was a problem hiding this comment.
in general.. thinking of this as a "template" - a "requirements" section would be in general a good thing to always include in this top level comment 💯
There was a problem hiding this comment.
mention that for local execution the gh cli tool and GH token need to be configured on the machine
Also check for both (as well as the env vars?) at the very beginning and fail if that's not present? Nobody ever reads the comments until they get such a strong indication they actually are gonna have to. It's always helpful if a script checks all prereqs first thing it does.
|
Thank you for this and for (probably even a bit too extensive) comments! 😀 this is great. I put one comment, but we don't need to bother with it now. Shellcheck prints me couple of info/warning messages but nothing serious, so again, can be handled later. I would consider this enough even without the logic for the branch detection and release tag computation. Though, since you have it there already - its great and let's go with it then 🙂 /lgtm |
|
We should consider adding a Shellcheck link. Maybe already it's time for https://pre-commit.com? Posting the above as a GitHub issue, will turn it into Jira eventually /lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED Approval requirements bypassed by manually added approval. This pull-request has been approved by: 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:
Approvers can indicate their approval by writing |
This commit is a follow up from discussions on opendatahub-io#472. The following improvements have been made to the script: - Set the executable bit on the script - Default values provided for all variables now (including `output_file`) so the script can and should be ran simply as `./generate-component-metadata.sh` - Any and all issues reported by `shellcheck` have been resolved - Comments have been added for the file as a whole, as well as on each function, to help improve understanding of the script and its implementation. The "comment template" used is a continuation from the one I experiemented with in opendatahub-io#484 Related-to: https://issues.redhat.com/browse/RHOAIENG-12524
This commit is a follow up from discussions on opendatahub-io#472. The following improvements have been made to the script: - Set the executable bit on the script - Default values provided for all variables now (including `output_file`) so the script can and should be ran simply as `./generate-component-metadata.sh` - Default name now honors the guidance given via a [Slack discussion](https://redhat-internal.slack.com/archives/C05NXTEHLGY/p1734032874172439?thread_ts=1731327116.001979&cid=C05NXTEHLGY) - i.e. `Kubeflow Notebook Controller` - Any and all issues reported by `shellcheck` have been resolved - Comments have been added for the file as a whole, as well as on each function, to help improve understanding of the script and its implementation. The "comment template" used is a continuation from the one I experiemented with in opendatahub-io#484 Related-to: https://issues.redhat.com/browse/RHOAIENG-12524
Description
This commit replaces the "placeholder" create-release.yaml file to include functionality to actually create a
opendatahub-io/kubeflowrelease following the original manual process.The GHA can be invoked manually as a workflow from GitHub as well as invoked as part of the kubeflow-release action.
kubeflow-release.yamlhas been modified to pass in the target branch name for cutting the release. The release/tag name is NOT provided as thecreate-release.shscript will auto-compute what the proper tag name should be.create-release.shwill also handle auto-updating the release tag for future scenarios where we change the target branch (ex:v1.9-branchtov2.0-branch).Please see the (extensive) comments in
.github/scripts/create-release.shfor deeper explanation on implementation.yamlof the action. I find it more pleasant to read/develop when the script is in its own file - and also allows code editors to be smarter in offering hints on the source.Related-to: https://issues.redhat.com/browse/RHOAIENG-15391
How Has This Been Tested?
Changes were originally tested by developing the GitHub action against my own repository - mimic'ing the branching names used by
opendatahub-io/kubeflowFollowing testing scenarios were covered when manually launching the workflow:
Merge criteria: