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

Display file sizes and module breakdown on pull requests #3282

Closed
4 tasks
Tracked by #3279
romaricpascal opened this issue Feb 13, 2023 · 1 comment · Fixed by #4039
Closed
4 tasks
Tracked by #3279

Display file sizes and module breakdown on pull requests #3282

romaricpascal opened this issue Feb 13, 2023 · 1 comment · Fixed by #4039

Comments

@romaricpascal
Copy link
Member

Part of #3279

What

Add a comment on PR that summarises the statistics collected from the content of our package. This may include (to keep below the 65536 character limit of comments):

  • file size inside dist
  • file size of package/govuk/all.js
  • link to review app for file sizes of other files in package/govuk
  • size and number of modules for each file going through rollup-plugin-visualizer, with a link to the review app for the actual breakdown

The comment should include the SHA of the commit the stats relate to, so we can check it is up to date with the tip of the PR branch. To cater for times where this may get out of sync, the workflow collecting the stats should be runnable manually.

If possible, the code for posting comments on the PR should be made generic so we can re-use it to add other comments on the PR (for example the diff of dist).1

Why

Having these information accessible in the review app is handy, but hidden away. Commenting on the pull requests will give us more immediate access to the information.

Who needs to work on this

Developers

Who needs to review this

Developers

Done when

  • An existing or new workflow comments on our PRs with the stats2
  • Either:
    • The code for commenting on the PR is generic
    • or
    • An issue was created to make the code generic

Footnotes

  1. The approach could be the same as in the spike, but using a comment as marker to recognise the comment rather than actual content in the comment.

  2. Little note of caution around trying not to increase the build time on CI too much

@stevenjmesser
Copy link

Needn't block a pre-release, but we would like to do this before a full public release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging a pull request may close this issue.

5 participants