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

lotus-releaser: release issue creation #12477

Open
BigLep opened this issue Sep 17, 2024 · 0 comments
Open

lotus-releaser: release issue creation #12477

BigLep opened this issue Sep 17, 2024 · 0 comments
Milestone

Comments

@BigLep
Copy link
Member

BigLep commented Sep 17, 2024

Done Criteria

A release engineer can answer some questions and get the corresponding release issue created to cover these realistic scenarios:

  1. minor release for a network upgrade
  2. minor release for a non-network upgrade
  3. normal patch release against current minor release
  4. emergency patch release against current minor release
  5. emergency patch release against previous minor release

There should also be a Node vs. Miner dimension.

Why Important

https://github.com/filecoin-project/lotus/blob/master/documentation/misc/RELEASE_ISSUE_TEMPLATE.md is non-trivial at this point and requires various manual step depending on the release type one is doing. This takes time each release and is somewhat error prone.

This is heightened during high-severity events like we had with #12467 . In that case, releasers went off script because the desired script couldn't be generated quickly enough. We ended up not following https://github.com/filecoin-project/lotus/blob/master/LOTUS_RELEASE_FLOW.md in that we didn't first merge changes to master and the changelog entries were varied between the patches.

This also serves as a initial simple beach head to incrementally add more tooling/automation to the release process so we can start reducing the number of steps in the checklist.

User/Customer

Maintainers / releasers

Notes

  1. By "emergency patch release" I mean likely just one commit and no RC.
  2. I think this is the data input the scripting needs to take to get the permutations above:
    1. Is this for node or miner?
    2. Is this for a network upgrade? If so, what network version?
    3. Is this a minor release?
    4. Is this a patch release? If yes, what previous release are you patching?
    5. Is this an emergency patch? (If yes, we can skip RC steps)
  3. While the initial hope is just to spit out a URL that a release engineer can click to get the release pre-populated, I think we can build towards something like https://github.com/ipfs/kuboreleaser so that more of the steps are automated and standardized.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 🐱 Todo
Development

No branches or pull requests

1 participant