You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ci: use shared cache-header deploy action for all storybook publishes (#5219)
* ci: use shared cache-header deploy action for all storybook publishes
The cache-header fix in #5206 only changed publish_storybook.yaml, but
production Storybook is deployed by the publish-storybook job in
publish_core_react.yaml (dispatched with environment=production on every
release). That job — and publish_lab.yaml / publish_data_grid.yaml — used
tibor19/static-website-deploy@v4, which sets no Cache-Control headers, so
Azure Front Door fell back to its 48h default and the stale-cache Manager
crash from #5205 kept happening in prod after every release.
Extract the deploy logic from #5206 into a composite action
(.github/actions/deploy-storybook) and use it in all four workflows:
- immutable cache headers on hashed assets/*, no-cache on the rest
- zero-downtime overwrite-then-delete-stale instead of delete-all-first
- skip the assets/ upload when the build has no assets directory
The publish jobs check out .github explicitly because the setup job's
sparse checkout only includes packages/apps/scripts. The az login/logout
steps are dropped: --connection-string is complete authentication on its
own.
Closes#5212
* ci: document deploy action assumptions and checkout ordering
Follow-ups from review:
- action.yml: note the az CLI runner dependency, that static-website
hosting / container access policy are pre-existing account config the
action does not re-apply (unlike tibor19/static-website-deploy), and
that the stale cleanup requires one storage account per environment.
- all four workflows: state explicitly that the sparse .github checkout
must stay the first step, since checkout cleans the workspace and
would wipe the restored storybook build.
- publish_storybook.yaml: align the checkout comment with the other
three workflows.
* ci: authenticate az via env var instead of --connection-string argument
The Azure CLI reads AZURE_STORAGE_CONNECTION_STRING from the environment,
so the flag was redundant — and passing the secret as an argument exposes
it in process args on the runner (GitHub masks logs, not argv).
0 commit comments