| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
The JSON check previously only reported syntax errors; it didn't block merges and couldn't fix anything. This adds: - scripts/validate_json.py: validates the top-level *.json files, with a --fix mode that repairs minor syntax issues (trailing commas, etc.) via json_repair, and a --restore-fallback mode that reverts a file to its last known-good version from git history if a repair isn't safe (e.g. it would drop most of the entries). - On pull_request (same-repo branches): auto-repairs and pushes the fix back to the PR branch; still fails the check if something can't be fixed, so it can be made a required status check to block merging. - On push to main (direct commits): auto-repairs, falling back to restoring the last known-good version, so main is never left pointing at broken JSON that the app would choke on. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…urrently, see PR)
…token The default GITHUB_TOKEN deliberately doesn't trigger new workflow runs when it pushes (anti-recursion protection). Verified this live on PR #247: the fix commit landed but never got its own check run, which would permanently block merging once this becomes a required status check. Push with STORE_AUTOMATION_TOKEN instead so the fix commit re-triggers CI and reports its own green check. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
| Back | FazBrowse Home | New Git URL |
Summary
Verified live on this PR
Known open issue — do not make this a required status check yet
Even using STORE_AUTOMATION_TOKEN (confirmed to be a valid, non-empty secret), the auto-fix commit is not reliably getting its own new check run in testing — same symptom as with the default token. Root cause isn't nailed down (ruled out: token being empty/misconfigured). Until this is understood, making this check required on main could leave a PR stuck showing no status for its current HEAD even though the file is already valid, which would block merges instead of just protecting them. Recommend holding off on the branch-protection change until this is resolved or someone confirms the behavior is more reliable outside of rapid back-to-back test pushes.
Test plan