[ngarakapati]

Why

The publish step added in #52 fails on every merge to main. On each push it rebuilds build/ui-bundle.zip and pushes it directly to main as github-actions[bot]. main is protected, so the push is rejected:

• Changes must be made through a pull request (org-level rule), and
• Required status check "build" is expected (repo ruleset) — a direct push can never carry a passing check.

You can see this on the #53 merge run: the bundle builds fine, then the push is declined and the job exits 1.

Trying to make the bot push to main would need a PAT or a GitHub App token on the bypass list, plus loop guards. That is a lot of moving parts for a docs UI repo.

What this does

Stop auto-committing the bundle. Contributors rebuild it locally and commit it in their PR, so it goes through the normal reviewed + checked path like any other file:

nvm use          # Node 20, per .nvmrc
npm ci
npx gulp bundle  # writes build/ui-bundle.zip
git add build/ui-bundle.zip

CI now only:

• on PRs: runs npx gulp bundle (lint + build) — this is the required build check,
• on merge to main: pings Netlify so the docs sites rebuild and pull the committed bundle.

Result

• No bot pushes to main, so the protected-branch failures stop for good.
• No CI-created binary commits piling onto main.
• No token, no GitHub App, no org-ruleset change.
• permissions drop to contents: read.
• The consumer URL (blob/main/build/ui-bundle.zip?raw=true) is unchanged, so no docs-repo change is needed.

Trade-off

CI cannot verify the committed bundle is fresh — the zip embeds file timestamps, so a CI rebuild never byte-matches a locally built one. If someone changes src/ but forgets to rebuild, the docs show stale styling until a fresh bundle is committed. Reviewers should check that a src/ change includes a rebuilt build/ui-bundle.zip.

[Tushar-TG-14]

@ngarakapati

1. Since the bundle is now built and committed in the PR, should the Build UI bundle and artifact steps run only for PRs? On a push to main, CI currently rebuilds/uploads the bundle again before triggering Netlify.
2. The main remaining risk seems to be a stale committed build/ui-bundle.zip. Can we detect when src/ changes but the committed bundle wasn't updated? Otherwise the PR could pass while the docs still consume an older bundle.

[ngarakapati]

Good calls, addressed both in the latest push.

1. The artifact upload now only runs on PRs. The docs sites read the committed zip from main, not the Actions artifact, so uploading it on the main push was dead weight. I kept the build step on main as a cheap smoke test in case two PRs break main together.

2. Can't compare the zip directly: it stores file timestamps so it's never byte-identical, and unzip-comparing fails too since image minification differs between Mac and the Linux runner. So instead the PR now fails if src/ changed but build/ui-bundle.zip didn't. That catches the forgot-to-rebuild case cleanly. It won't catch a bundle built from stale source, but that's rare and a reviewer would see it.

[ngarakapati]

Went one further and dropped the artifact upload entirely. Since the bundle is committed in the PR, the artifact just duplicated a file already in the branch. Reviewers can grab the zip from the PR branch, and the docs read the committed zip from main. Nothing consumed it.