Compiler emits deprecated `actions/upload-artifact@v3` / `download-artifact@v3`, causing hard HTTP 400 on every run

[darwin-gonzales]

Summary

gh aw compile generates lock files that pin actions/upload-artifact@v3.2.2 and actions/download-artifact@v3.1.0. GitHub retired the v3 artifact backend, so every activation run now fails at the Upload activation artifact step with HTTP 400 Bad Request from the legacy artifact API. This makes any freshly-initialised workflow non-functional out of the box.

The failure is not transient (reproduced across multiple reruns with GitHub status all-green) and is not fixed by upgrading: the current stable v0.81.6 and the latest pre-release v0.82.1 both emit the same v3 pins.

Impact

• Any workflow compiled with current gh-aw fails on the first artifact upload.
• The failing job is activation -> step Upload activation artifact; all downstream jobs (agent, detection, safe_outputs, conclusion) are skipped, so the agent never runs.
• The only workaround is hand-editing the generated .lock.yml to v4 SHAs, which contradicts the file's DO NOT EDIT header and is reverted by the next gh aw compile.

Environment

• gh-aw: v0.81.6 (latest stable) - also reproduced on v0.82.1 (pre-release)
• gh CLI: 2.93.0
• Runner: ubuntu-latest (GitHub-hosted)
• Engine: GitHub Copilot CLI (copilot 1.0.65)

Reproduction

1. gh aw init

2. Create any *.aw.md workflow (e.g. an issue-triggered fixer).

3. gh aw compile

4. Inspect the generated lock file:

   grep -n 'uses: actions/\(upload\|download\)-artifact@' .github/workflows/<name>.aw.lock.yml
   

   Observed (all executable uses: lines):

   uses: actions/upload-artifact@c6a366c94c3e0affe28c06c8df20a878f24da3cf   # v3.2.2
   uses: actions/download-artifact@a9bc5e6ef2cb54c177f32aa5726adaa15e7e2d59 # v3.1.0
   

5. Trigger the workflow. The Upload activation artifact step fails.

Actual failure log

Run actions/upload-artifact@c6a366c94c3e0affe28c06c8df20a878f24da3cf
With the provided path, there will be 19 files uploaded
Starting artifact upload
Artifact name is valid!
Create Artifact Container - Error is not retryable
##### Begin Diagnostic HTTP information #####
Status Code: 400
Status Message: Bad Request
###### End Diagnostic HTTP information ######
Error: Create Artifact Container failed: The artifact name activation is not valid.
Request URL https://pipelinesghubeus21.actions.githubusercontent.com/.../_apis/pipelines/workflows/<run-id>/artifacts?api-version=6.0-preview

Note the endpoint (_apis/pipelines/workflows/.../artifacts?api-version=6.0-preview) is the legacy v3 artifact API, and the action self-reports Artifact name is valid! immediately before the backend rejects it - the name is fine; the API is retired.

Root cause

The v3 artifact actions call the old artifact service, which GitHub decommissioned. See the official deprecation notice: https://github.blog/changelog/2024-04-16-deprecation-notice-v3-of-the-artifact-actions/

gh-aw appears to hardcode the v3 pins in its embedded workflow templates, so recompiling (even on the newer pre-release) re-emits them.

Expected behaviour

Compiler should pin actions/upload-artifact@v4 and actions/download-artifact@v4.

Suggested pins (SHAs verified against the upstream repos):

• actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
• actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0

Migration note for the maintainers

v4 requires artifact names to be unique within a run (v3 allowed re-uploading to the same name and merged them). In the generated lock file the upload names are already distinct (activation, agent, usage, aic-usage-cache, detection, safe-outputs-items), so a straight v3->v4 pin swap works without collisions in this case - but any template that uploads to the same artifact name from multiple jobs/steps will need overwrite: true or unique names under v4.

Workaround (for anyone hitting this before a fix ships)

Manually replace the SHAs in the generated .lock.yml with the v4 SHAs above (all occurrences). This is a stopgap - it is reverted by the next gh aw compile, so it must be re-applied after every recompile until the compiler is fixed.

[github-actions]

🔍 Workflow Health Manager — Jul 2 Assessment

Severity: P0 (Critical/Systemic)

This is the top-priority systemic issue identified in today's health scan. Impact summary:

• All freshly-initialized workflows fail at the Upload activation artifact step with HTTP 400
• gh aw compile continues to emit actions/upload-artifact@v3.2.2 and actions/download-artifact@v3.1.0 — both retired by GitHub
• Affects every workflow using the default compiled lock file template

Health Score Impact: Contributing to today's score drop (73/100, ↓2 from Jul 1). This is rated P0 as it blocks all new workflow adoption.

Recommended fix: Bump compiler output to actions/upload-artifact@v4 and actions/download-artifact@v4. All existing .lock.yml files should be recompiled after the fix.

References: §28568253334

Generated by 🏥 Workflow Health Manager - Meta-Orchestrator · 73.6 AIC · ⌖ 8.52 AIC · ⊞ 7.8K · ◷