Summary

The main branch CI is red, but the failure is not a code/test regression — it is the GitHub Pages deploy step in the Documentation job failing with a 403.

On the last two pushes to main (4fd77f1 = merge of #34, 5621b49 = merge of #32), 8 of 9 jobs pass (lint, test ×3 toolchains, coverage, security, msrv, conformance). Only the docs job fails, at the deploy step:

##[group]Push the commit or tag
[command]/usr/bin/git push origin --force gh-pages
remote: Permission to evlinked/ocpp-rs.git denied to github-actions[bot].
fatal: unable to access 'https://github.com/evlinked/ocpp-rs.git/': The requested URL returned error: 403
##[error]Action failed with "The process '/usr/bin/git' failed with exit code 128"

(Failing run: https://github.com/evlinked/ocpp-rs/actions/runs/27484378443 — job Documentation.)

Why PR builds are green but main is red

The deploy step is gated on push-to-main only:

# .github/workflows/ci.yml  (docs job)
- name: Deploy to GitHub Pages
  if: github.event_name == 'push' && github.ref == 'refs/heads/main'
  uses: peaceiris/actions-gh-pages@v3
  with:
    github_token: ${{ secrets.GITHUB_TOKEN }}
    publish_dir: ./target/doc
    force_orphan: true

So PRs (pull_request event) skip the deploy and stay green, while every push to main runs it and fails. This is why nightly PRs #36 and #37 both show passing CI even though main is red. The cargo doc build itself succeeds; only the push to the gh-pages branch is denied.

Root cause

github-actions[bot] does not have write access to the repo, so it cannot push the gh-pages branch. This is a repo/workflow permissions setting, not a code problem. Default GITHUB_TOKEN permissions are read-only unless the repo is configured otherwise or the workflow declares permissions:.

Recommended fix (owner decision — needs a permissions change I'm not allowed to make)

The nightly automation guardrails forbid it from changing CI workflow permissions or secrets, so this is left for a maintainer. Any one of the following resolves it:

1. Repo setting — Settings → Actions → General → Workflow permissions → select Read and write permissions. Lowest-effort; no file change.
2. Scoped workflow permission — grant write only where needed, e.g. on the docs job:

   docs:
     name: Documentation
     permissions:
       contents: write   # allow pushing the gh-pages branch

3. Migrate to the official Pages pipeline — replace peaceiris/actions-gh-pages with actions/upload-pages-artifact + actions/deploy-pages, using permissions: { pages: write, id-token: write } and a github-pages environment. This is the modern, recommended approach and avoids force-pushing a gh-pages branch.

Recommendation: option 1 or 2 for a quick green, and consider option 3 as a follow-up (it also clears the peaceiris/actions-gh-pages@v3 Node.js 20 deprecation warning flagged in the same run).

Acceptance criteria

• A push to main produces a fully green CI run (Documentation job included)
• GitHub Pages docs are published (or the deploy step is intentionally removed/made non-blocking if Pages isn't wanted)
• No regression to the other 8 jobs

Notes

• Part of M0 Bootstrap & CI.
• Filed by the nightly automation as a finding; the actual fix requires a maintainer because it touches workflow/repo permissions (outside the automation's allowed scope).