[ngarakapati]

What this is

Today, every Antora UI change also needs a local gulp bundle and a committed build/ui-bundle.zip. Other docs repos only pick up the new look after that zip is on main.

This PR makes CI do the zip step. Docs playbooks do not change. They still load the bundle from GitHub main. No new secrets. We still use the existing Netlify hook.

How it works

On a pull request

• CI runs gulp bundle.
• If that fails, the PR should not be merged.
• The zip is not committed from the PR.
• You can download the zip from the Actions artifact to try locally.

After merge to main

• CI runs gulp bundle again.
• If the zip changed, it commits build/ui-bundle.zip to main, then pings Netlify once.
• If the zip did not change (for example README-only), it does not commit a zip and does not ping Netlify.

New habit for the team

1. Change UI source only.
2. Preview locally with gulp preview if you want.
3. Open a PR without ui-bundle.zip.
4. Merge when CI is green.
5. Wait for Actions. The bot publishes the zip. Docs pick it up from main.

Follow-up (needs a repo admin)

After this merges, protect main and require the build check so a red PR cannot be merged.

Test plan

• Confirm this PR's Actions run runs gulp bundle (not only the Netlify curl).
• Confirm this PR does not ping Netlify.
• Confirm the built zip is available as an Actions artifact.
• After merge, confirm Actions commits build/ui-bundle.zip if it changed.
• Confirm Netlify is pinged once, not twice.
• Confirm docs sites still load the bundle from the same GitHub URL.
• (Admin) Require the build check on main so a red PR cannot merge.

[Tushar-TG-14]

@ngarakapati

1. Since the workflow will now push the generated ui-bundle.zip directly to main, can we enable branch protection and require the build check before merging? Should this be done as part of this PR rather than later?
2. What happens if another commit is pushed to main while the bundle is being built? Is the git pull --rebase step safe in that case, especially if ui-bundle.zip was also changed?
3. Since this is a CI build and we have a package-lock.json, is there a reason we're using npm install instead of npm ci? Would npm ci be better to make the build use the exact locked dependencies?

[ngarakapati]

Thanks for the review. Answers below.

1. Yes, we should require the build check on main so a red PR cannot merge. That is a GitHub repo setting, not something this workflow file can turn on. We should do it after this PR is merged, not as part of this PR. If we require build first, PRs still run the old job (the Netlify curl) and fork PRs fail because they do not get BUILD_HOOK. After this lands, build means gulp bundle passed. Then an admin can protect main and require build.

2. The old git pull --rebase was not safe. ui-bundle.zip is a binary, so if main moved (or another job also wrote the zip) we could get a conflict or publish the wrong zip. That is updated in this PR: rebase is gone. Jobs on main wait in line instead of running at the same time. If main moved or the push is rejected, we rebuild from the latest main and retry the push.

3. No good reason to use npm install here. We have package-lock.json, so CI should install exactly those versions. This PR now uses npm ci --no-audit.

[ngarakapati]

For question 1, here is how an admin can require the build check after this PR is merged.

Rulesets

1. Open this repo → Settings.
2. Left sidebar: Rules → Rulesets.
3. New ruleset → New branch ruleset.
4. Name it something like Protect main.
5. Set Enforcement status to Active.
6. Target branches → Add target → Include default branch (main).
7. Check Require status checks to pass.
8. Add checks, search for build, and select it. That is the job name in this workflow.
9. Optional: Require branches to be up to date before merging.
10. Click Create.

If the repo still uses classic branch protection

1. Settings → Branches → Add branch protection rule.
2. Branch name pattern: main.
3. Check Require status checks to pass before merging.
4. Search for and select build.
5. Save.

After that, a red build on a PR blocks merge. A green build is required to merge.

Do this after this PR is merged, so build means gulp bundle passed, not the old Netlify curl.

[Tushar-TG-14]

@ngarakapati After merging #52, the new build job is failing during npx gulp bundle.

The failure is in lint:css with:

ERR_PACKAGE_PATH_NOT_EXPORTED: Package subpath './lib/input' is not defined by "exports" in node_modules/postcss/package.json

It comes through postcss-syntax/parse-style.js.

Checkout, Node setup, and npm ci pass, but gulp bundle fails before the artifact/publish/Netlify steps. I haven't rerun it yet. Could you check the PostCSS/postcss-syntax dependency compatibility?

[ngarakapati]

The red build after merge is this PostCSS / Node mismatch, not a CSS change. #52 started running gulp bundle on Node 20. The old CSS linter still needs PostCSS 8.1's ./ exports fallback, which Node 17+ removed.

Fix is in a follow-up PR: pin CI to Node 16 so lint:css can run and the bundle can publish.

#53