Skip to content
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

Open
didierofrivia opened this issue Feb 10, 2025 · 4 comments
Assignees

Comments

@didierofrivia
Copy link
Member

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.

@Boomatang
Copy link
Contributor

I think #1166 could affect the understand of how this work should happen.

@Boomatang
Copy link
Contributor

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 release.toml file?

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.

@didierofrivia
Copy link
Member Author

@Boomatang since we are using yq everywhere, maybe we could use yaml instead, what do you reckon?

@Boomatang
Copy link
Contributor

With hesitation I will flip the file format from toml to yaml.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: In Progress
Development

No branches or pull requests

2 participants