-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix and match automated release process with the new manifest driven one #1163
Comments
I think #1166 could affect the understand of how this work should happen. |
There is a design choice that is being done in #1150 that may need to be changed by what might be happening here. Is this work going to be updating the The reason I ask the question is. Toml was design to be human readable, writable and machine readable. It was not designed to be machine writable. We may need to change the file format depending on if and how this work is planning deal with that file. |
@Boomatang since we are using |
With hesitation I will flip the file format from I do what it to be noted. I do not believe we should automate the updating of that. I do believe some friction in the release process is good, unless the release are going to be continuous, as in on every PR merge we release, but we are never going to be doing that. However this is not a hill I am willing to fight for, but it does make me uneasy. |
Is your feature request related to a problem? Please describe.
Currently the automated release workflow, a.k.a "Release Button" is lacking verification step and patch/pre-release identifiers compatibility.
It also should aligned with the new proposed workflow that uses a new manifest for the release information.
Describe the solution you'd like
When the release workflow is triggered, it should create a PR with the required changes, completing the manual local steps that are exposed in the new workflow in order to be peer reviewed. Once the PR is approved and merged to the release branch, it should continue to do the rest of the release steps that currently has. The workflow would look more or less to:
Release button with dependencies versions input ->
release-X.Z
brach created if it doesn't exist -> PR with the full version (including patch and pre-release annotations) using the previous created branch as base (images are also build) -> once approved, git tag created and release published.The text was updated successfully, but these errors were encountered: