Re-think webpack memory metrics CI job
Now that we have enabled incremental compiling by default in the GDK (gitlab-development-kit!2146 (merged)), webpack's memory footprint should be reduced significantly for average users. @markrian brought up some points regarding the usefulness of the CI job tracking memory metrics and its corresponding chart in light of these changes.
We have a
webpack-dev-server
job in CI (added in gitlab-foss!31537 (merged)), which I believe the intention of is to track the memory usage of webpack.If we enable incremental compiling by default, that job probably won't be useful anymore:
- Either we leave it as-is, in which it will probably only build the handful of default bundles and nothing else, which is not representative of normal usage; or
- Disable incremental compiling specifically for that job, in which case it's no longer testing the default setup, and so is less useful.
I think our intention was to enable incremental compiling in this CI job as well so that we can see the typical memory consumption for GDK users, but this will certainly be less accurate now. WDYT, should we still do this? Is this metric still useful?
We have seeded about 23 common entrypoints to the compiler history for first-time uses. In combination with the two "always present" entrypoints and the non-page-specific entrypoints (sentry, performance_bar, etc) we probably have a decent baseline that we can use for this CI job even if it's not 100% accurate to an average user's configuration.