Improve generate-release workflow involving editing and merging notes and guides
#1650
Conversation
It now tracks whether a PR exists by the PRs metadata, and allows for mutliple PRs per a note, and PR URLs per note. It should only ever create a file if a PR is not included in any notes metadata, so no more overwriting note files or note metadata if it isn't a new PR as far as the generator is concerned.
TrialDragon
added
C-Usability
A-Migration Guides
C-Code Quality
A-Release-Notes
S-Waiting-On-Author
C-Automation
|
There should probably be a documentation pass to double check it's good once it is functional, but before it is ready for review (mostly a note for myself, so I don't forget). Especially for updating the README.md for the tool, and the relevant sections in the Contributing Guide. |
|
Ping me once this is ready for review! :) |
|
A note for whomever generates the contributors list for 0.15; for some reason there is a contributor listed as |
|
@BD103 The PR is ready for review. |
TrialDragon
added
S-Needs-Review
D-Straightforward
and removed
S-Waiting-On-Author
labels
generate-release/README.md
Outdated
| @@ -4,12 +4,14 @@ This CLI tool is used to generate all the skeleton files required to create a ne | |||
|
|
|||
| For a bit more background see this issue: <https://github.com/bevyengine/bevy-website/issues/1163> | |||
|
|
|||
| All commands assume they are ran in the `/generate-release` folder. | |||
| The commands can be run from anywhere inside the workspace folder. | |||
There was a problem hiding this comment.
Maybe it's obvious, but this is true as long as the .env file is at the root. cargo run -p generate-release wasn't working in the project root, then I realised that I had my .env file in the /generate-release folder (from the previous release). 😓
There was a problem hiding this comment.
Maybe it's obvious, but this is true as long as the
.envfile is at the root.cargo run -p generate-releasewasn't working in the project root, then I realised that I had my.envfile in the/generate-releasefolder (from the previous release). 😓
Should be a warning in the README now.
| @@ -1,779 +1,779 @@ | |||
| [[guides]] | |||
| title = "Overhaul `Color`" | |||
| url = "https://github.com/bevyengine/bevy/pull/12163" | |||
| prs = ["12163",] | |||
content/learn/contribute/project-information/release-process.md
Outdated
Show resolved
Hide resolved
generate-release/README.md
Outdated
| @@ -4,12 +4,14 @@ This CLI tool is used to generate all the skeleton files required to create a ne | |||
|
|
|||
| For a bit more background see this issue: <https://github.com/bevyengine/bevy-website/issues/1163> | |||
|
|
|||
| All commands assume they are ran in the `/generate-release` folder. | |||
| The commands can be run from anywhere inside the workspace folder. | |||
There was a problem hiding this comment.
Maybe it's obvious, but this is true as long as the .env file is at the root. cargo run -p generate-release wasn't working in the project root, then I realised that I had my .env file in the /generate-release folder (from the previous release). 😓
Co-authored-by: Asier Illarramendi <asier@illarra.com>
|
Awesome, I'm so happy this is finally happening! I opened up TrialDragon#7 in case you agree to remove the trailing comma in the TOML. |
Co-authored-by: BD103 <59022059+BD103@users.noreply.github.com>
Also adds the generate contributors list step under generate-release too.
TrialDragon
added
S-Ready-For-Final-Review
I think it's a perfectly valid contributor "name". The tool should take care to escape the string instead? |
|
The name could be replaced by their Github handle, @CrazyboyQCD. |
|
Oh wow, TIL those aren't the same... |
Objective
Fixes #1354
Fixes #1350 I believe
Adds support for Meta category labels to the
generate-releasetool solving #1646 (comment)This PR aims to make the release notes and migration guides generators easier to use with merged release notes, and edited release notes. (Also, overall improving the tool in slight ways as I go along, by accident).
Solution
It now tracks whether a PR exists by the release note and migration guide metadata, and allows for multiple PRs per a note or guide, and PR URLs per note or guide. It should only ever create a file if a PR is not included in any notes or guides metadata, so no more overwriting note files or note or guide metadata if it isn't a new PR as far as the generator is concerned. If a release note or migration guide PR is removed from the entries, and has no notes or guides associated with it's number, it will be regenerated and appended to the end of the metadata file whilst preserving the preexisting notes or guides.
This PR also edits the Zola page templates to create the URls from the
prslist in the metadata, and migrated the 0.14 release note and migration guides to work with this system.The Contributing guide and
generate-releaseREADME.md have been slightly updated.Testing
Run the tool:
cargo run -p generate-release -- --from v0.14.2 --to main --release-version 0.15 release-notesto initially generate, then modify the notes entries inrelease-content/0.15/release-notes/_release-notes.tomland or in the related PR files, then re-run the tool to see how it doesn't modify your edits, but if you removed a PR completely (isn't in any of the notes associated metadata), then it will regenerate that one note and appends it to the end of the file while preserving the other notes.cargo run -p generate-release -- --from v0.14.2 --to main --release-version 0.15 migration-guidesto do the same for migration guides (same testing methodology, too).To test the Zola pages, you can follow the instructions in
generate-release's README.md for generating a release to create the initial files. Then, runzola serveto A) see the site start up locally, hopefully without errors (be aware that the contributors subcommand may produceWX\shixias a contributor name, which breaks Zola, and so has to be deleted for Zola to work), and B) check the mock news post to see if everything looks correct, or acceptable.