feat(build-cli): New command transform:releaseNotes #22466
Conversation
github-actions
bot
added
area: build
| @@ -72,7 +72,7 @@ jobs: | |||
| with: | |||
| name: release-metadata | |||
| path: release-metadata.json | |||
| retention-days: 3 | |||
| retention-days: 30 | |||
There was a problem hiding this comment.
What's the motivation here?
There was a problem hiding this comment.
I had some trouble debugging since all the artifacts were gone. Now that we're releasing ~monthly, this felt like a reasonable time period to ensure there would usually be an artifact around to use for investigation/debugging. The file is also super small. Regardless, though, debugging was my main reason. Probably worth a comment.
|
|
||
| static readonly flags = { | ||
| inFile: Flags.file({ | ||
| description: `A release notes file that was generated using 'flub generate releaseNotes'. The file must not already contain heading links. That is, the input file must not have been generated with the --headingLinks flag.`, |
There was a problem hiding this comment.
What happens if it was generated with --headingLinks? Can we detect if it was and react appropriately (throw?)?
There was a problem hiding this comment.
I'll test it - probably possible to detect but not sure how much it's worth - maybe just stripping anchor tags and regenning them in the remark pipeline will be easier.
There was a problem hiding this comment.
It turns out that this is the reason to check if the first child node of a heading is text - if I add that check back, then it works even when links have been generated, because it skips them. So I added that check back.
build-tools/packages/build-cli/src/commands/transform/releaseNotes.ts
Outdated
Show resolved
Hide resolved
| public async run(): Promise<string> { | ||
| const { inFile, outFile } = this.flags; | ||
| const input = await readFile(inFile, { encoding: "utf8" }); | ||
| const processor = remark() |
There was a problem hiding this comment.
Any chance of refactoring common bits between this and generate:releaseNotes so the two commands stay in sync?
There was a problem hiding this comment.
I haven't found a great way to do that yet, but I am looking. The problem is that the order of the pipeline matters, and the typing is complex enough that I haven't successfully modularized a "chunk" of the pipeline - only the individual plugins/functions. I am positive this is possible and I just haven't found a workable pattern yet.
Co-authored-by: Alex Villarreal <[email protected]>
…otes.ts Co-authored-by: Alex Villarreal <[email protected]>
build-tools/packages/build-cli/src/commands/transform/releaseNotes.ts
Outdated
Show resolved
Hide resolved
build-tools/packages/build-cli/src/commands/transform/releaseNotes.ts
Outdated
Show resolved
Hide resolved
Co-authored-by: jzaffiro <[email protected]>
Co-authored-by: jzaffiro <[email protected]>
Co-authored-by: jzaffiro <[email protected]>
|
Thanks for the review, @jzaffiro! |
The transform:releaseNotes command was added in #22466 to enable automated release note creation for minor releases. This change updates the CI pipeline to take advantage of the new capabilities. [AB#19242](https://dev.azure.com/fluidframework/235294da-091d-4c29-84fc-cdfc3d90890b/_workitems/edit/19242) --------- Co-authored-by: Alex Villarreal <[email protected]>
The problem
Our goal is to automate the release process as much as possible. To that end, now that we have a release notes generator, we'd like to automatically upload those notes to the GitHub release as part of the automated release.
Unfortunately, when we generate changelogs as part of release, we consume and delete all the changesets for the release. However, we generate a markdown file with the release notes as part of the release, and that gets committed to the repo. Alas, we need the markdown to be slightly different when posted to GitHub releases, and we don't have the input changesets anymore, so we can't easily regenerate them in automation (we'd need to find the commit in which the changesets were consumed, go to the commit before, regenerate - it's not trivial).
The proposed change
Since we have the release notes files in the repo, I have created a new command,
transform:releaseNotes, which takes the in-repo release notes file as input, and outputs a modified markdown file for use in the release pipeline. For example:flub transform releaseNotes --inFile RELEASE_NOTES/2.2.0.md --outFile out.md