-
Notifications
You must be signed in to change notification settings - Fork 5k
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
Refactor changelog parsing and generation #10847
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Gudahtt
force-pushed
the
changelog-refactor
branch
from
April 8, 2021 00:27
dcc953b
to
50df31f
Compare
Builds ready [50df31f]
Page Load Metrics (656 ± 50 ms)
|
Gudahtt
force-pushed
the
changelog-refactor
branch
from
April 8, 2021 00:45
50df31f
to
554d153
Compare
Builds ready [554d153]
Page Load Metrics (601 ± 69 ms)
|
The `auto-changelog.js` script has been refactoring into various different modules. This was done in preparation for migrating this to a separate repository, where it can be used in our libraries as well. Functionally this should act _mostly_ the same way, but there have been some changes. It was difficult to make this a pure refactor because of the strategy used to validate the changelog and ensure each addition remained valid. Instead of being updated in-place, the changelog is now parsed upfront and stored as a "Changelog" instance, which is a new class that was written to allow only valid changes. The new changelog is then stringified and completely overwrites the old one. The parsing had to be much more strict, as any unanticipated content would otherwise be erased unintentionally. This script now also normalizes the formatting of the changelog (though the individual change descriptions are still unformatted). The changelog stringification now accommodates non-linear releases as well. For example, you can now release v1.0.1 *after* v2.0.0, and it will be listed in chronological order while also correctly constructing the `compare` URLs for each release.
Gudahtt
force-pushed
the
changelog-refactor
branch
from
April 8, 2021 14:29
554d153
to
459b991
Compare
Builds ready [459b991]
Page Load Metrics (582 ± 39 ms)
|
brad-decker
approved these changes
Apr 8, 2021
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Output looks good for both baseline and --rc flag, code looks much cleaner and broken into fairly easy-to-digest pieces. LGTM 👍🏻 Especially like the amount of comments / docblocks to explain what each piece does.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
auto-changelog.js
script has been refactoring into various different modules. This was done in preparation for migrating this to a separate repository, where it can be used in our libraries as well.Functionally this should act mostly the same way, but there have been some changes. It was difficult to make this a pure refactor because of the strategy used to validate the changelog and ensure each addition remained valid. Instead of being updated in-place, the changelog is now parsed upfront and stored as a "Changelog" instance, which is a new class that was written to allow only valid changes. The new changelog is then stringified and completely overwrites the old one.
The parsing had to be much more strict, as any unanticipated content would otherwise be erased unintentionally. This script now also normalizes the formatting of the changelog (though the individual change descriptions are still unformatted).
The changelog stringification now accommodates non-linear releases as well. For example, you can now release v1.0.1 after v2.0.0, and it will be listed in chronological order while also correctly constructing the
compare
URLs for each release.Relates to #10752
Manual testing steps:
To update the changelog with unreleased changes:
yarn update-changelog
To update the changelog for a release candidate:
yarn update-changelog --rc