CI: scope down Next.js Bundle Analysis workflow and gate it behind a GitHub environment
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 1.6k
- Forks
- 155
- Avg merge
- 1d 18h
- Merged PRs (30d)
- 20
Description
The Next.js Bundle Analysis workflow (.github/workflows/nextjs-bundle-analysis.yml) runs far more often than it needs to, and is not tied to a GitHub environment.
Problem
The analyze job triggers on every pull_request (all branches except main/next) and every push to canary. Each run does a full npm ci, npm run build of the whole monorepo, and a webpack Next.js build of examples/next/faustwp-getting-started, solely to produce a bundle-size comparison comment for that one example app.
This is excessive because it also runs on PRs where the example bundle cannot meaningfully change, e.g.:
- Dependabot dependency-bump PRs
- The automated
changeset-release/canary(Version Packages) PRs - Plugin-only, docs-only, and other unrelated changes
The full monorepo + Next.js build on every one of these is slow and burns CI minutes for no signal.
Current triggers
on:
pull_request:
branches-ignore:
- 'main'
- 'next'
push:
branches:
- 'canary'
workflow_dispatch:
The workflow declares no environment:.
Proposed changes
- Gate the
analyzejob behind a dedicated GitHub environment (e.g.bundle-analysis), so runs are controllable and any protection rules live in one place — consistent with how the wordpress.org deploy job usesenvironment: wordpress-org. - Add
paths:filters so it only triggers when the example app or the packages it bundles actually change (e.g.examples/next/faustwp-getting-started/**,packages/**). - Skip automated/bot PRs (Dependabot,
changeset-release/*).
Acceptance criteria
- Bundle analysis no longer runs on unrelated or bot-generated PRs.
- It runs only when the example app or its bundled dependencies change.
- The
analyzejob is gated behind a GitHub environment.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with .github/workflows/nextjs-bundle-analysis.yml, reviewing its current triggers and analyze job; compare the environment pattern used by the wordpress.org deploy job. Scope paths to the example app and bundled packages, exclude the named automated PRs, and gate analyze behind a dedicated environment. Done means unrelated or bot-generated PRs are skipped while relevant changes still produce bundle analysis.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, next.js, typescript
- Domain
- ci-cd, devops
- Issue type
- Refactor
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 72/100