Two related visibility gaps, fixed together since both ride on the same
nightly build:
1. superset-storybook.netlify.app has been live and populated with real,
current component stories the whole time (Netlify's own git integration
auto-builds and deploys it, no CI workflow involved) -- but there was no
link to it anywhere in the repo. Added a README badge.
2. BUNDLE_ANALYZER=true npm run build has always produced a browsable
treemap of what's actually in the bundle, but only ever locally, on
request. Now rides along in the same nightly build that already refreshes
the bundle-size baseline (BUNDLE_ANALYZER and BUNDLE_SIZE_STATS are
independent env-gated additions to webpack.config.js, so one production
build produces both), publishing the treemap (report.html) to Netlify --
the same host already trusted for Storybook and docs previews, reusing
the existing NETLIFY_AUTH_TOKEN secret. Deliberately does not publish the
sibling statistics.html sunburst chart: webpack.config.js documents it as
routinely exceeding 100MB for this app (it's .gitignore'd for exactly
that reason), too large for a static site page.
The Netlify publish step is gated on NETLIFY_BUNDLE_ANALYZER_SITE_ID and
no-ops until that secret exists -- safe to merge now. Turning it on just
needs a new (free) Netlify site named superset-bundle-analyzer and its
site ID added as that secret; nothing else in the workflow depends on it.
The README badge points at that same URL in anticipation.
Persisting a new baseline on every push to master (which happens many
times a day) burns a full production build each time for no benefit a
once-a-day refresh doesn't already cover -- a day-old baseline is fine for
catching relative regressions on PRs. Moves baseline persistence to a new
frontend-bundle-size-nightly.yml (schedule + workflow_dispatch), and
restricts superset-frontend.yml's bundle-size job to pull_request only:
compare-and-alert against the last nightly baseline, never persist.
Also caches webpack's persistent filesystem build cache
(superset-frontend/.temp_cache) across CI runs via actions/cache, keyed on
the same files webpack's own `buildDependencies` invalidates on. Without
this, every PR run would pay the full cold-build cost (several minutes)
instead of the ~20s warm-build cost the cache is supposed to buy --
GH-hosted runners are fresh VMs with nothing carried over between jobs, so
the cache has to be restored explicitly or it does nothing.
Superset's frontend bundle size is a recurring complaint, but until now
there's been no ongoing visibility into it -- only periodic manual cleanup
efforts. This adds a `bundle-size` job to superset-frontend.yml that builds
the real production bundle (npm run build), reduces its per-entrypoint
sizes to a few headline numbers, and tracks them over time via
benchmark-action/github-action-benchmark, posting a PR comment when a
change regresses past 110% of the last recorded baseline.
Reuses the already-built CI Docker image (same image sharded-jest-tests /
lint-frontend / etc. already download), so the only new cost is the
production webpack build itself -- and that's cheap after the first run:
webpack's persistent filesystem cache (already configured in
webpack.config.js) makes warm rebuilds ~20s locally vs several minutes
cold, confirmed by hand against this repo's real build.
webpack.config.js gains a BUNDLE_SIZE_STATS env-gated stats override
(mirrors the existing BUNDLE_ANALYZER pattern). The default `stats:
'minimal'` omits per-asset sizes entirely; `--stats=normal` includes them
but also serializes the full ~15k-module dependency graph, producing a
560+MB stats.json for this app -- large enough to exceed Node's max
string length on a plain fs.readFileSync. The env-gated override requests
just `{ assets: true, entrypoints: true }`, verified end-to-end against a
minimal synthetic webpack project (same webpack/webpack-cli versions) and
against real stats pulled from this repo's actual production build.
History storage deliberately avoids the gh-pages branch (benchmark-action's
usual default) since that branch is the live Helm chart index published by
superset-helm-release.yml, not free real estate. Instead uses
external-data-json-path with actions/cache: restored on every run (PR or
push) so PRs get a same-baseline comparison and regression comment, but
only saved back to the cache on push to master, so an unmerged PR's numbers
never become the shared baseline. No gh-pages branch is touched in any
code path, and no PAT/GitHub App is needed -- comment-on-alert only needs
the default per-job GITHUB_TOKEN.
