Repository navigation
feat(ci): deploy reports through native Pages with verified design assets - #363
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configuration
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
🚀 Preview is available for this pull request. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 84dff3f41a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| group: reports-pages | ||
| cancel-in-progress: false |
There was a problem hiding this comment.
Because the packaged wrapper triggers both pull requests and pushes to main, this workflow-level constant places every build and production deployment in the same concurrency group. GitHub allows only one running and one pending run by default, and a newer run replaces the pending one even when cancel-in-progress is false (GitHub concurrency documentation). Thus, while one PR build runs, a pending main deployment can be canceled by another PR update and never publish; use event/ref-specific groups or apply deployment concurrency only to the deploy job.
Useful? React with 👍 / 👎.
| touch .dev-tools/reports/.nojekyll | ||
| rm -rf .dev-tools/reports/cache | ||
| test -f .dev-tools/reports/index.html | ||
| test -f .dev-tools/reports/coverage/index.html |
There was a problem hiding this comment.
When a consumer has no testable PHP source, ReportsCommand deliberately skips coverage and returns success after generating the applicable report surfaces (src/Console/Command/ReportsCommand.php:194-201), so coverage/index.html is absent. This unconditional assertion then fails an otherwise successful native Pages build, although the operator guide does not require tests or autoloaded PHP source; detect generated surfaces as the legacy reports workflow does instead of requiring coverage.
Useful? React with 👍 / 👎.
| printf '%s %s\n' "$LOGO_SHA" "$RUNNER_TEMP/published-logo.svg" | sha256sum --check --strict | ||
| printf '%s %s\n' "$DASH_SHA" "$RUNNER_TEMP/published-dash.png" | sha256sum --check --strict |
There was a problem hiding this comment.
When a deployment changes either asset, Pages or its CDN can temporarily return the previous file with HTTP 200. These one-shot checksum commands then fail immediately because curl considers the preceding downloads successful; --retry-all-errors only retries when curl encounters an error, as documented in the curl manual. Wrap each download and checksum comparison in the bounded retry loop so normal propagation does not mark a successful deployment as failed.
Useful? React with 👍 / 👎.
| dash-sha: ${{ steps.identity.outputs.dash_sha }} | ||
| steps: | ||
| - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7 | ||
| with: |
There was a problem hiding this comment.
This checkout omits fetch-depth, so the pinned action fetches only one commit by default (actions/checkout documentation). MetricsCommand nevertheless always invokes PhpMetrics with --git git (src/Console/Command/MetricsCommand.php:136-142), causing published history-derived metrics to reflect only the shallow tip rather than the repository history. The legacy reports workflow already avoids this with fetch-depth: 0; apply the same setting to this consumer checkout.
Useful? React with 👍 / 👎.
1 participant
Ten consumers have GitHub Pages configured for Actions, but their Reports wrapper calls the legacy gh-pages publisher. Regenerating that branch does not deploy the selected Pages source.
Add a separate native Pages reusable workflow and an explicit optional wrapper/operator guide. Existing reports.yml and legacy consumers keep their current behavior. Native PR builds generate documentation, coverage and metrics with read-only credentials; only the checkout-free main-branch deployment job receives Pages/OIDC permission. Consumer plugin allowlists remain unchanged. The signed phpDocumentor tool is installed in an isolated Composer project with only its official plugin allowed; missing GPG, failed installation or missing signature-verification evidence stop the build.
Require template >=2.1.0 and log the actual selected version/reference. Compare generated Dash/logo bytes to the installed package, and compare public assets after deployment to SHA-256 outputs from that build. Adoption requires consumer-local DevTools; the wrapper is outside automatic sync and does not implement legacy previews/cleanup schedules.
Validation:
The template release is published at https://github.com/php-fast-forward/phpdoc-bootstrap-template/releases/tag/v2.1.0 and available on Packagist. Existing ^2.0 constraints already accept it. Four current documentation sites have been regenerated and their public identity bytes verified; native consumer adoption follows this PR. Asset hash verification proves the two identity assets, not the complete HTML/CSS output; rollout also inspects rendered pages. Pages settings and branch protections are unchanged.