[bgm-malbeclabs]

Summary

• A push to main publishes the built site to GitHub Pages again, so a merged change reaches docs.malbeclabs.com without a manual step.
• The publish job takes only the permissions Pages needs (pages: write, id-token: write), uses no repository secrets, and runs only on main. The github-pages environment also accepts deploys from main only.
• The build installs an exact, hashed set of Python packages from requirements.txt (mkdocs 1.6.1, mkdocs-material 9.8.0, mkdocs-static-i18n 1.3.1 and their dependencies), because what it builds is now what Pages publishes. requirements.in holds the three top-level pins, and the workflow comment gives the command that regenerates the file.
• Runs on main queue instead of cancelling each other, so a started Pages deploy finishes. PR runs still cancel older runs on the same branch.
• PR runs still only build and check the site. Vercel publishing for docs.doublezero.xyz is not part of this change.

Testing

• The pinned set installs with pip install --require-hashes on Python 3.12. The build gives only the known i18n warning, and its output matches the build deployed to docs.doublezero.xyz today, file for file apart from sitemap.xml.
• actionlint passes on the workflow. The actions-lint check runs zizmor on this PR.
• After merge, the push run should show a deploy-pages job, and docs.malbeclabs.com should serve main, without the Binance page.

[nikw9944]

The publish job looks right. One change I'd make before merging, because this PR turns an existing gap into a path to the production site.

Checked

• Deploys only from main, enforced twice:
  • deploy-pages runs only for non-PR events on refs/heads/main;
  • the github-pages environment's branch policy also allows only main, so a workflow_dispatch from another branch can't deploy either.
• Least privilege:
  • the workflow default stays contents: read;
  • only the deploy job gets pages: write and id-token: write;
  • no secrets, and no cloud role trusts this repo, so id-token grants nothing beyond Pages.
• Pins: upload-artifact v4.6.2 and deploy-pages v4.0.5 both resolve to their tags.
• PR runs only build. On this PR, deploy-pages is skipped and build and actions-lint are green.
• Packaging with tar --dereference matches what upload-pages-artifact does, and keeps .well-known. Pages is in workflow mode with docs.malbeclabs.com, so this is the right target.

Requested: pin the build's Python dependencies

• The build runs pip install mkdocs-material mkdocs-static-i18n with no versions. Until now that only affected a CI check. With this PR, whatever PyPI serves at build time is what gets published to docs.malbeclabs.com.
• A compromised or broken release of mkdocs-material, the i18n plugin or one of their dependencies could inject script into the site, or change the install commands readers copy from it.
• It's already drifting: ci: re-enable Actions CI: build-only docs workflow, disabled deploy.yml, actions-lint #217 was verified with mkdocs-material 9.7.7, PyPI now serves 9.8.0, and that's what this PR's CI used.

Suggested fix: a requirements.txt generated with pip-compile --generate-hashes, pinning mkdocs==1.6.1, mkdocs-material and mkdocs-static-i18n==1.3.1 and their dependencies. The build step then becomes pip install --require-hashes -r requirements.txt. Exact == pins without hashes would close most of the gap; hashes are better for something that publishes. Pick the mkdocs-material version you want to verify against, and confirm the build log's warnings are unchanged.

Optional: the workflow-level concurrency cancels an in-progress run when a newer one starts on the same ref. For Pages, GitHub's starter workflow uses cancel-in-progress: false on the deploy, so a deploy isn't cut off partway. The newer push redeploys anyway, so this is minor.