ci: pin actions to SHA in 8 broken workflows

[giattijunior]

Summary

Fix the 8 pre-existing workflows in giattijunior/gstack that have been silently failing with startup_failure due to a policy conflict between sha_pinning_required: true and allowed_actions: selected (custom allowlist with empty patterns).

The skillspector.yml was previously untracked in the repo; this PR adds it with the same SHA-pinning treatment.

Background

Discovered while debugging the dupehound workflow in #1: every workflow in this repo that used actions/checkout@v4 (tag-based) failed at parse time with startup_failure — no jobs ever ran, no logs produced, 0-second runs. The 7 pre-existing workflows broken by this were:

• actionlint.yml (Workflow Lint)
• ci-image.yml (Build CI Image)
• cve-lite.yml
• evals-periodic.yml (Periodic Evals)
• evals.yml (E2E Evals)
• renovate.yml
• skill-docs.yml (Skill Docs Freshness)
• skillspector.yml (SkillSpector)

Fix

Pin every tag-based uses: reference to its current commit SHA in all 8 affected files. Actions pinned in this PR:

• actions/checkout@v4 → 34e114876b0b11c390a56381ad16ebd13914f8d5
• actions/setup-node@v4 → 49933ea5288caeca8642d1e84afbd3f7d6820020
• actions/setup-python@v4 → 7f4fc3e22c37d6ff65e88745f38bd3157c663f7c
• actions/setup-python@v5 → a26af69be951a213d495a4c3e4e4022e16d87065
• actions/upload-artifact@v4 → ea165f8d65b6e75b540449e92b4886f43607fa02
• actions/download-artifact@v4 → d3f86a106a0bac45b974a628896c90dbdf5c8093
• docker/login-action@v3 → c94ce9fb468520275223c153574b00df6fe4bcc9
• docker/build-push-action@v3 → 1104d471370f9806843c095c1db02b5a90c5f8b6
• docker/build-push-action@v6 → 10e90e3645eae34f1e60eeb005ba3a3d33f178e8
• astral-sh/setup-uv@v6 → d0d8abe699bfb85fec6de9f7adb5ae17292296ff
• oven-sh/setup-bun@v2 → 0c5077e51419868618aeaa5fe8019c62421857d6
• rhysd/actionlint@v1.7.11 → 393031adb9afb225ee52ae2ccd7a5af5525e03e8
• renovatebot/github-action@v41 → 7e1c0fa7cfd2c3e91b27cdd87ae09a6a0fafb5f2 (v41.0.0)
• github/codeql-action/upload-sarif@v4 → 411bbbe57033eedfc1a82d68c01345aa96c737d7

The repo enforces sha_pinning_required: true against all tag-based uses: references, not just actions/checkout. Fixing only the latter was insufficient; cve-lite workflow (which uses setup-node, codeql-action, upload-artifact) still failed with startup_failure until all of them were pinned.

CI status (this PR)

Workflow	Before this PR	After this PR
Workflow Lint	startup_failure	success
Skill Docs Freshness	startup_failure	success
cve-lite	startup_failure	failure (see below)
E2E Evals	startup_failure	queued (uses ubicloud-standard-2 runner, slower)
Periodic Evals	startup_failure	not run (schedule-only)
Build CI Image	startup_failure	queued (Docker build, slower)
Renovate	startup_failure	not run (schedule-only)
SkillSpector	(file untracked)	pending first run

The two success results confirm the fix works. The 4 queued workflows are still expected to succeed once they complete — they use heavier runners (Docker, ubicloud) and take longer to spin up.

Out of scope: cve-lite CLI bug discovered

With the workflow now actually running for the first time, it failed with:

Error: cannot combine --sarif and --report
Run `cve-lite --help` to see supported options.

The cve-lite.yml invokes cve-lite . --fail-on high --sarif --no-open --report ./cve-report — the --sarif and --report flags are mutually exclusive. This is a pre-existing bug in the workflow (or the cve-lite CLI) that has been hidden by the startup_failure of the SHA pinning issue. Fixing it requires deciding which output format to use (SARIF for Code Scanning integration or HTML for artifacts) — that's a separate decision and a separate PR.

Caveats

• Pinned SHAs will need periodic bumps to track upstream releases. Renovate is already configured in this repo but only updates the workflows Renovate itself owns; manual bumps will be needed for the others, or Renovate config can be extended.
• Node.js 20 deprecation: pinned v4 actions run on Node 20 which GitHub will force to Node 24 starting June 16, 2026. If a future v4 release targets Node 24, bumping the SHA picks up the upgrade.

Related

• docs: add README and CLAUDE.md #1 — first PR where the diagnosis happened; now also passing.

[trunk-io]

Merging to main in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

[sonukapoor]

Hi @giattijunior - just spotted this PR. Thanks for the detailed debugging work on the SHA pinning.

I am the creator of the CVE Lite CLI.

On the cve-lite workflow: I can see you are trying to get both SARIF output for Code Scanning and an HTML report as a downloadable artifact - that is a well-designed setup. The problem is that --sarif and --report are currently mutually exclusive in CVE Lite CLI. I have opened an issue to lift that restriction so both can be used in a single command.

In the meantime, you can get both outputs by splitting into two steps:

- name: Scan dependencies
  id: scan
  run: |
    set +e
    cve-lite . --fail-on high --sarif
    SCAN_EXIT=$?
    echo "scan_exit=$SCAN_EXIT" >> "$GITHUB_OUTPUT"
    ls -la *.sarif 2>/dev/null || true
    exit $SCAN_EXIT

- name: Generate HTML report
  if: always()
  run: cve-lite . --report ./cve-report --no-open

The SARIF upload and HTML artifact upload steps can stay exactly as they are.

[sonukapoor]

Quick follow-up: the --sarif + --report restriction has been lifted in v1.24.0. You can simplify to a single scan step:

- name: Scan dependencies
  run: cve-lite . --fail-on high --sarif --report ./cve-report --no-open

The SARIF upload and HTML artifact steps stay the same.