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

Refactor changelog parsing and generation #10847

Merged
merged 1 commit into from
Apr 8, 2021
Merged

Conversation

Gudahtt
Copy link
Member

@Gudahtt Gudahtt commented Apr 8, 2021

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:

  • Run yarn update-changelog
  • See that it puts changes under the "Unreleased" header

To update the changelog for a release candidate:

  • Run yarn update-changelog --rc
  • See that it puts changes under the header for the current release candidate

@Gudahtt Gudahtt force-pushed the changelog-refactor branch from dcc953b to 50df31f Compare April 8, 2021 00:27
@metamaskbot
Copy link
Collaborator

Builds ready [50df31f]
Page Load Metrics (656 ± 50 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint48796284
domContentLoaded37382765510450
load37582865610450
domInteractive37382665410450

@Gudahtt Gudahtt marked this pull request as ready for review April 8, 2021 00:45
@Gudahtt Gudahtt requested review from kumavis and a team as code owners April 8, 2021 00:45
@Gudahtt Gudahtt requested a review from darkwing April 8, 2021 00:45
@Gudahtt Gudahtt force-pushed the changelog-refactor branch from 50df31f to 554d153 Compare April 8, 2021 00:45
@metamaskbot
Copy link
Collaborator

Builds ready [554d153]
Page Load Metrics (601 ± 69 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint448157105
domContentLoaded367106560014569
load368106660114469
domInteractive366106460014569

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 Gudahtt force-pushed the changelog-refactor branch from 554d153 to 459b991 Compare April 8, 2021 14:29
@metamaskbot
Copy link
Collaborator

Builds ready [459b991]
Page Load Metrics (582 ± 39 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint45795894
domContentLoaded4046815818239
load4096825828139
domInteractive4036815808239

Copy link
Contributor

@brad-decker brad-decker left a 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.

@Gudahtt Gudahtt merged commit 312f2af into develop Apr 8, 2021
@Gudahtt Gudahtt deleted the changelog-refactor branch April 8, 2021 18:44
@github-actions github-actions bot locked and limited conversation to collaborators Apr 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants