wpengine / wpengine/faustjs

CI: scope down Next.js Bundle Analysis workflow and gate it behind a GitHub environment

Open
#2,457 0 comments 0 reactions 0 assignees View on GitHub

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

  1. Gate the analyze job 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 uses environment: wordpress-org.
  2. 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/**).
  3. 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 analyze job is gated behind a GitHub environment.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.