Decide whether spotlight-validator should be public — its output already is #7

Activity

1. kinlane

   added

   decisionWaiting on a call, not on effortWaiting on a call, not on effort

   on Aug 18, 2026
2. kinlane commented on Aug 18, 2026

   

   kinlane

   on Aug 18, 2026

   ContributorAuthor

   More actions

   This now has a concrete consequence: the deploy workflow cannot succeed

   CI is green on main again after spotlight-validator#11. The deploy workflow is a separate failure, and it has failed on every run since the repo was restored — three for three:

   Commit	deploy
   294a2eff (the CI fix merge)	failure
   ae883875	failure
   704398b9 (the RFC 9457 pass)	failure

   The build succeeds and uploads its artifact. Deployment is what fails:

   Creating Pages deployment with payload: { "artifact_id": ..., "pages_build_version": "294a2eff..." }
   ##[error]Creating Pages deployment failed
   ##[error]HttpError: Not Found
   ##[error]Error: Failed to create deployment (status: 404)
   

   Why

   Three facts, each verified:

   • GET /repos/api-commons/spotlight-validator/pages → 404. Pages is not enabled.
   • The repo is private.
   • The api-commons org is on the free plan.

   GitHub Pages on a private repo requires Pro/Team/Enterprise. On a free plan, Pages is public-repos-only. So deploy cannot be made to pass while this repo stays private — the workflow is not misconfigured, it is asking for something the current combination does not allow.

   This is a consequence of the restore choice. The repo was recreated as private on purpose, because republishing something that had been removed from the org is a decision to take deliberately. That was the right call to leave open — but it has a cost that is now visible in CI.

   Which turns this issue into a fork in the road

   1. Make it public. Pages works, deploy goes green, and the 740 rules become inspectable at their source — which the site already publishes anyway.
   2. Keep it private and remove the deploy workflow, since it can never succeed. The site is generated in the hub from all-rules.yaml, so this repo does not need to publish anything itself.

   What should not happen is leaving a workflow that fails on every commit — it trains everyone to ignore red, which is exactly how spotlight-validator#11 sat unnoticed on main for hours.
3. kinlane commented on Aug 18, 2026

   

   kinlane

   on Aug 18, 2026

   ContributorAuthor

   More actions

   Resolved: made public.

   Both consequences the issue described are now settled.

   What changed

   • api-commons/spotlight-validator is public.
   • GitHub Pages enabled with build_type: workflow, matching the actions/deploy-pages step the workflow already used. Pages had never been enabled on the restored repo — that 404 was the deployment failure.
   • The deploy run that had failed three times for three was re-run: build success, deploy success.
   • The validator is live at https://api-commons.github.io/spotlight-validator/ — Spotlight Validator — API Governance Playground, HTTP 200.

   main is now green on both workflows for the first time since the repo was restored.

   Scanned before publishing

   Full history — 64 commits — plus the working tree, for API keys, tokens, private keys and Slack/AWS/Google credential patterns. Clean. The only embedded identifier is a Google Analytics measurement ID (G-YJEJYCXZH3), which is public by design and already visible in the page source of the deployed site.

   What this settles

   The 740 rules published at apicommons.org/rules now have an inspectable source. Anyone can read rules/all-rules.yaml, see where a rule came from, propose a fix, or check its provenance — which is what an organization premised on open, provenanced governance should allow.

   It also removes the split where the output was public and the source was not.
4. kinlane

   closed this as completedon Aug 18, 2026