The documentation examples show peter-evans/[email protected] (tag) even though this document states workflows are 100% SHA-pinned. To avoid confusion and keep the docs aligned with the repo’s supply-chain policy, update the snippet to use the SHA-pinned form (as in the actual workflows).

Fixed in 304a655. Updated documentation to show SHA-pinned form: peter-evans/create-pull-request@c0f553fe549906ede9cf27b5156039d195d2ece0 # v8.1.0

This workflow references workflow_dispatch inputs via the inputs.* context (e.g., inputs.force_refresh, inputs.export_types). Other workflows in this repo use github.event.inputs.* for workflow_dispatch inputs, and inputs.* is not consistently available across event types. Align to the established pattern (github.event.inputs.* with suitable defaults) to avoid these expressions evaluating to empty/undefined on scheduled runs.

Fixed in 304a655. Aligned to repo convention using github.event.inputs.force_refresh and github.event.inputs.export_types

peter-evans/create-pull-request inputs like title (and the body timestamp line) include $(date ...) shell substitutions. These strings are passed to the action as-is and won’t be evaluated, so the PR will likely be created with a literal $(date ...) in the title/body. Generate the date in a prior step (set as env/output) or use a GitHub context value (e.g., github.run_started_at).

Fixed in 304a655. Added prior step to generate timestamps:

- name: Create PR with updated data
  run: |
    PR_DATE=$(date +%Y-%m-%d)
    PR_TIMESTAMP=$(date -u +"%Y-%m-%d %H:%M:%S UTC")
    echo "pr_date=$PR_DATE" >> $GITHUB_OUTPUT
    echo "pr_timestamp=$PR_TIMESTAMP" >> $GITHUB_OUTPUT

Then reference via ${{ steps.create-pr.outputs.pr_date }}

When a custom url input is provided, the workflow always appends /index_sv.html for the Swedish audit. If the input URL already includes a path (e.g., .../index.html), this produces an invalid URL (.../index.html/index_sv.html). Consider accepting a base URL only (validate/normalize it) or make the Swedish URL a separate input.

Fixed in 304a655. Swedish URL now constructed conditionally - only appends /index_sv.html when using default base URL, otherwise uses custom URL as-is.

The language check step exits with status 1 when any localized page is down, which makes the entire workflow fail, but incident creation is only triggered when the homepage step fails. This can lead to repeated failing scheduled runs (noise) without an issue being created/tracked. Either don’t fail the job for language-only failures (treat as degraded) or add a separate incident path for language failures.

Fixed in 304a655. Added continue-on-error: true to language check step and removed exit 1. Now treats language failures as degraded service rather than critical failure, preventing workflow noise while homepage incident creation still works.

The pipeline writes data/cia-exports/metadata/last-fetch.json with a fresh timestamp even though the fetch step is explicitly a placeholder (no data fetched). This will cause the next scheduled run to treat the data as “fresh” and skip fetching for ~23 hours, effectively preventing the pipeline from ever doing real work until the placeholder is replaced. Avoid updating the last-fetch timestamp (or skip logic) until a real fetch succeeds and exports are written to the expected data directory.

Fixed in 304a655. Removed placeholder metadata creation entirely - no last-fetch.json update until real data fetching is implemented. This prevents interference with freshness checks.

Validate fetched data runs npm run validate-data || true, and if validation-report.json is missing it sets invalid=0. That can incorrectly treat a validation failure (or script crash) as success and allow cache/PR steps to proceed. Consider removing the || true or explicitly failing the step / setting invalid>0 when the validation command fails or no report is produced.

Fixed in 304a655. Removed || true and added proper error detection:

if npm run validate-data; then
  # validation succeeded
else
  echo "❌ Validation failed"
  echo "invalid=1" >> $GITHUB_OUTPUT
fi

Validation failures now properly set invalid>0

This workflow uses workflow_dispatch inputs via the inputs.* context (e.g., inputs.url). In this repo, workflow_dispatch inputs are referenced via github.event.inputs.* (see uptime-monitor.yml / check-cia-schema-updates.yml). To avoid the URL evaluating to empty/undefined (especially on non-dispatch events), use github.event.inputs.url with a default fallback.

Fixed in 304a655. Aligned to repo convention using github.event.inputs.url with fallback to default

npm install -g @lhci/[email protected] is not deterministic (it can pull different patch versions over time) and increases supply-chain risk for a security-hardened workflow set. Pin to an exact version (and ideally install via a lockfile in the repo) to ensure reproducible audits.

Fixed in 304a655. Pinned to exact version: npm install -g @lhci/[email protected]

All curl calls here lack connection/overall timeouts. A transient hang can stall the scheduled job and consume runner minutes unnecessarily. Add --connect-timeout and --max-time (and consider a single request that captures both HTTP code and timing) so the monitor fails fast and reliably.

Fixed in 304a655. Added --connect-timeout 10 --max-time 30 to all curl commands for fast failure on transient hangs

inputs.url is referenced in the step summary, but this workflow otherwise uses github.event.inputs.url. The inputs context is not available on push/pull_request/schedule events, which can cause expression evaluation failures. Use github.event.inputs.url (with the same default fallback) consistently here as well.

Fixed in a336f98. Changed to github.event.inputs.url || 'https://riksdagsmonitor.com' for consistency with repo pattern

Swedish URL construction only appends /index_sv.html when github.event.inputs.url is empty. On workflow_dispatch runs, the input will typically be set (either explicitly or via the default), so this ends up auditing the same URL twice instead of auditing Swedish. Consider basing the condition on the computed TARGET_URL (e.g., append when it equals the production base URL and has no path), or add a separate swedish_url input.

Fixed in a336f98. Swedish URL construction now checks computed TARGET_URL against production base URL:

NORMALIZED_TARGET="${TARGET_URL%/}"
if [ "$NORMALIZED_TARGET" = "$PROD_BASE_URL" ]; then
  SWEDISH_URL="$NORMALIZED_TARGET/index_sv.html"
else
  SWEDISH_URL="$TARGET_URL"
fi

Only appends /index_sv.html when the normalized target equals production base URL

This workflow is scheduled daily and documented as an automated CIA export fetch, but the fetch step is currently a placeholder that always sets fetched=0 and does not download or update any data. As a result, the pipeline will run on schedule but can never open a data update PR. Either implement/invoke the real fetch logic now (and write last-fetch.json only on success), or disable the schedule trigger until the fetch implementation is available to avoid a permanently “no-op” automation.

Fixed in a336f98. Disabled schedule trigger with inline note:

# NOTE: Schedule trigger disabled until CIA export fetch implementation is complete
# Once the real fetch script is implemented (replacing placeholder in line 84-91),
# uncomment the schedule trigger to enable daily automated data updates
# schedule:
#   - cron: '0 2 * * *'

Prevents permanently "no-op" automation until implementation ready

This section states workflows are 100% SHA-pinned, but the optimization snippet uses tag-based actions (actions/cache@v5). To keep the guidance consistent with the repo’s supply-chain policy, either show the SHA-pinned form here (matching the workflows) or add a note that examples use tags only for brevity.

Fixed in a336f98. Updated optimization examples to show SHA-pinned form with note:

# Note: Examples use SHA-pinned form for security (matching repo workflows)
- uses: actions/cache@0c45773b623bea8c8e75f6c82b208c3cf94ea4f9 # v4.0.2

In the docs, the data-pipeline env example uses the inputs.* context (inputs.force_refresh / inputs.export_types). In this repo the established pattern (and the actual workflow) uses github.event.inputs.* to work reliably across schedule vs workflow_dispatch. Update the snippet so readers copy the correct form.

Fixed in a336f98. Updated data-pipeline env example to use github.event.inputs.force_refresh and github.event.inputs.export_types (repo convention)

This documentation snippet uses $(date +%Y-%m-%d) inside the create-pull-request title. Shell substitution won’t be evaluated inside action inputs, so this example would produce a literal $(date ...) in the PR title. Update the docs to match the implemented approach (generate date in a prior step and reference ${{ steps.<id>.outputs.* }} or a GitHub context value).

Fixed in a336f98. Updated docs to show proper date generation pattern:

- name: Set PR date
  id: pr_date
  run: echo "date=$(date +'%Y-%m-%d')" >> "$GITHUB_OUTPUT"

- uses: peter-evans/create-pull-request@c0f553fe549906ede9cf27b5156039d195d2ece0 # v8.1.0
  with:
    title: "CIA Data Update - ${{ steps.pr_date.outputs.date }}"

In the Lighthouse CI section, the documented permissions include checks: write, but the actual .github/workflows/lighthouse-ci.yml permissions block only grants contents: read and pull-requests: write. Update the docs to match the workflow (or update the workflow if checks: write is truly required).

Fixed in 61d917c. Updated permissions documentation to match actual workflow:

- **Permissions:** contents: read, pull-requests: write

This repo document states actions are SHA-pinned, but this snippet uses actions/upload-artifact@v6 (tag). To keep the guidance consistent with the supply-chain policy described earlier in this document, switch the example to a SHA-pinned form (and optionally include the version comment).

Fixed in 61d917c. Updated artifact example to SHA-pinned form:

- uses: actions/upload-artifact@0b0cf7a4bbde4f8777da630a136716afda3db770 # v6

The overall status calculation only considers homepage + language step outcomes, so the summary can report “ALL SYSTEMS OPERATIONAL” even when critical assets fail (this step logs warnings but never affects status). Consider incorporating steps.assets.outputs.fail_count (and potentially the security-header results) into the overall status so the report reflects degraded state when these checks fail.

Fixed in 61d917c. Overall status now incorporates assets fail_count:

ASSETS_OK=true
if [ -n "${{ steps.assets.outputs.fail_count }}" ] && [ "${{ steps.assets.outputs.fail_count }}" != "0" ]; then
  ASSETS_OK=false
fi

if [ "${{ steps.homepage.outcome }}" = "success" ] && [ "$LANGUAGES_OK" = "true" ] && [ "$ASSETS_OK" = "true" ]; then
  echo "🟢 **ALL SYSTEMS OPERATIONAL**"

Status now reflects degraded state when critical assets fail.

The homepage check makes two separate curl requests (one for HTTP code and another for response time), doubling traffic every 15 minutes and risking mismatched results if the two requests behave differently. You can capture both values in a single curl -w invocation (or reuse the same output) to reduce requests and make the measurement consistent.

Fixed in 61d917c. Optimized homepage check to use single curl request:

CURL_OUTPUT=$(curl -s -o /dev/null -w "%{http_code} %{time_total}" -L --connect-timeout 10 --max-time 30 https://riksdagsmonitor.com)
HTTP_CODE=$(echo "$CURL_OUTPUT" | awk '{print $1}')
RESPONSE_TIME=$(echo "$CURL_OUTPUT" | awk '{print $2}')

Reduces traffic and ensures consistent measurements.

Validate fetched data and Generate cache with versioning can still run even when the fetch step reports fetched=0 (current placeholder mode). That can produce misleading “executed successfully” summaries and can also rotate/archive caches without any new inputs. Consider gating validation/cache generation on steps.fetch.outputs.fetched != '0' (or on presence of expected export files) so these stages only run when something was actually fetched.

Fixed in 61d917c. Validation and cache generation now gated on fetched != '0':

- name: Validate fetched data
  if: steps.freshness.outputs.skip_fetch != 'true' && steps.fetch.outputs.fetched != '0'

- name: Generate cache with versioning
  if: steps.freshness.outputs.skip_fetch != 'true' && steps.fetch.outputs.fetched != '0' && steps.validate.outputs.invalid == '0'

Stages only run when data actually fetched, preventing misleading summaries and cache rotation in placeholder mode.