On tag-triggered runs, actions/checkout will check out the tag ref (detached HEAD). The later git-auto-commit step that commits docs will likely fail or push nowhere unless you explicitly check out the default branch (or set the git-auto-commit-action branch input). Consider checking out ${{ github.event.repository.default_branch }} when the goal is to commit generated docs back to the repo, and keep the tag-derived version separate.

Fixed in commit a30949c. Added ref: ${{ github.event.repository.default_branch }} to the checkout step to ensure docs are committed to the default branch instead of detached HEAD on tag-triggered runs.

is_prerelease is only sourced from workflow_dispatch input, so tag-based pre-releases like v1.0.0-rc.1 will be treated as non-prerelease. If you want tag-based prereleases to work, derive this output from the tag name (e.g., contains(version, '-')) in addition to the dispatch input.

Fixed in commit a30949c. Updated is_prerelease to detect pre-release from tag name: (github.event_name == 'workflow_dispatch' && github.event.inputs.prerelease) || contains(steps.get-version.outputs.version, '-'). Now automatically detects tags like v1.0.0-rc.1 or v1.0.0-beta.1 as pre-releases.

steps.get-version.outputs.is_prerelease is referenced here, but the get-version step only outputs version. This will render blank (and may mislead consumers). Use the job output needs.prepare.outputs.is_prerelease (or compute from the resolved version) instead.

Fixed in commit a30949c. Changed to use needs.prepare.outputs.is_prerelease instead of the non-existent step output.

The zip command lists many glob patterns (e.g. *.gif, *.svg). If any of these patterns have no matches in the repo root, zip typically exits non-zero ("name not matched"), which will fail the workflow. Prefer zipping the directory (e.g. zip -r ... .) with a clear exclude list, or enable nullglob/generate the file list so optional extensions don’t break the build.

Fixed in commit a30949c. Changed to zip -r homepage-$VERSION.zip . -x <exclusions> to zip the entire directory with explicit exclusions. This prevents failures when optional file patterns don't match and is more maintainable.

External link opened with target="_blank" should include rel="noopener noreferrer" to prevent reverse-tabnabbing and ensure safer cross-origin navigation.

Fixed in commit a30949c. Added rel="noopener noreferrer" to the external GitHub Releases link to prevent reverse-tabnabbing.

The “Full Changelog” link ends with ...$RESOLVED_VERSION, but your tags are v$RESOLVED_VERSION (per tag-template). As written, the compare link will likely 404. Update it to compare against v$RESOLVED_VERSION (or adjust templates) so the URL matches actual tag names.

This step only runs for workflow_dispatch, so tag-triggered releases will not update docs/VERSION.txt and docs/version.txt. If these files are intended to track every release, generate/update them for both tag and manual runs (using the already-computed version).

Fixed in commit a30949c. Removed the if: github.event_name == 'workflow_dispatch' condition so VERSION.txt and version.txt are now generated for both tag-triggered and manual releases.

The Pages deploy step publishes the checked-out master workspace (folder: .), not the built/minified release output from the build job. This means the “backup” site can diverge from the release artifact. Consider deploying an extracted build artifact (unzip into a staging dir) or re-running the same build/minify in this job and deploying that folder.

Fixed in commit a30949c. Added a step to extract the built release artifact and changed the deployment folder to release-deploy. The gh-pages site now deploys the minified release artifact instead of the master workspace, ensuring consistency with the release package.

The README lists lighthouse-report.html, but the workflow copies docs/lighthouse-*.html and also creates docs/lighthouse-summary.html. Update this to match the actual generated filenames so users can find the reports.

Fixed in commit a30949c. Updated docs/README.md to match actual generated filenames: lighthouse-*.html for individual reports and lighthouse-summary.html for the aggregated summary.

This README implies SBOM/attestation files are generated and committed into docs/, but the workflow generates them as release artifacts (uploaded/attached to the GitHub Release) rather than committing them under docs/. Clarify whether they should live in docs/ or adjust the text to point to the release assets instead.

Fixed in commit a30949c. Updated docs/README.md to clarify that SBOM and attestation files are published as GitHub Release assets, not committed to the docs/ directory. The README now clearly distinguishes between HTML/validation reports (committed to repo) and SBOM/attestations (attached to releases).

needs.prepare.outputs.is_prerelease is referenced while still inside the prepare job. The needs context is not available in the same job and will cause an expression evaluation error. Use the already-resolved version (and/or the workflow_dispatch input) to compute the pre-release flag within this step, or expose it as a step output and reference that instead.

Fixed in commit 135cbd4. Changed to compute pre-release status directly within the step instead of referencing needs.prepare.outputs (which isn't available in the same job). Now uses: github.event_name == 'workflow_dispatch' && github.event.inputs.prerelease == 'true' || contains(steps.get-version.outputs.version, '-')

The workflow_dispatch version input is used directly as a tag/ref name and embedded into filenames without any validation. This allows invalid tag names (or unexpected characters) to break the workflow or create surprising tags/artifacts. Add a strict format validation (e.g., ^v\d+\.\d+\.\d+(-[0-9A-Za-z.-]+)?$) and fail fast if the input/tag does not match.

Fixed in commit 135cbd4. Added strict version format validation with regex ^v[0-9]+\.[0-9]+\.[0-9]+(-[0-9A-Za-z\.-]+)?$ that fails fast with a clear error message if the version format is invalid.

On tag-triggered releases, the workflow checks out the default branch (ref: github.event.repository.default_branch) before generating HTML validation reports and writing docs/version.txt. This can make the generated documentation reflect a different commit than the tag being released (even though the version is derived from the tag). Consider generating docs from the tag/SHA being released, and then switching to the default branch only for committing/pushing the generated docs/ updates.

Set Version for release writes to docs/VERSION.txt and docs/version.txt before the workflow ensures docs/ exists (mkdir -p docs happens in the following step). This will fail if the directory is missing (e.g., first run or if the folder gets removed/renamed). Create/ensure the directory exists before writing these files (or move mkdir -p docs earlier).

Fixed in commit 135cbd4. Moved mkdir -p docs to run before writing VERSION.txt and version.txt files to ensure the directory exists for first run or if folder was removed.

In the docs/ tree example, README.md is labeled as “This file”, but this document is docs/WORKFLOW_DOCUMENTATION.md. This is confusing for readers trying to find the right entrypoint; update the comment to point at the correct file (or adjust the tree to include WORKFLOW_DOCUMENTATION.md).

Fixed in commit 135cbd4. Updated the docs tree to include WORKFLOW_DOCUMENTATION.md with "This file" comment pointing to the correct file.

The pinned action SHAs shown as “Implemented in release.yml” don’t match the actual pinned SHAs in .github/workflows/release.yml (e.g., anchore/sbom-action and actions/attest-sbom). Since this section is used as implementation evidence, it should be kept in sync with the workflow (or reference only the version, not a specific SHA, if you don’t want to track SHA churn in docs).

Fixed in commit 135cbd4. Removed specific SHA pins from SECURITY_ARCHITECTURE.md code examples, now showing only version tags (v0.22.2, v3.0.0) to avoid documentation churn while the actual workflow maintains SHA-pinned versions for security.

The SLSA “Parameterless” row claims there are no manual parameters (“Version from tags, no manual params”), but the workflow supports workflow_dispatch with user-provided version and prerelease inputs. Either qualify this statement as applying to tag-triggered releases only, or update the evidence/wording to match the current workflow behavior.

Fixed in commit 135cbd4. Clarified the SLSA Parameterless row to specify it applies to tag-triggered releases: "Tag push: version from tags; workflow_dispatch: manual version/prerelease inputs".