Repeated tarball download timeouts for external repos consuming gh-aw actions

[DimaBir]

Summary

External repositories using gh-aw compiled workflows are experiencing repeated tarball download timeouts when the GitHub Actions runner tries to fetch github/gh-aw during the "Prepare all required actions" phase.

Affected Run

• Repo: microsoft/security-devops-action
• Failed run: https://github.com/microsoft/security-devops-action/actions/runs/22921401914/job/66520532459
• Workflow: msdo-issue-assistant.lock.yml (compiled from msdo-issue-assistant.md via gh aw compile)
• gh-aw version: v0.43.23
• Action ref: github/gh-aw/actions/setup@9382be3ca9ac18917e111a99d4e6bbff58d0dccc

Error

The runner timed out 3 times (100s HttpClient.Timeout each) trying to download the tarball:

Download action repository 'github/gh-aw@9382be3ca9ac18917e111a99d4e6bbff58d0dccc' ##[warning]Failed to download action 'https://api.github.com/repos/github/gh-aw/tarball/9382be3ca9ac18917e111a99d4e6bbff58d0dccc'. Error: The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing. ##[warning]Back off 12.736 seconds before retry. ##[warning]Failed to download action ... (2nd attempt, same error) ##[error]Action download has timed out. (3rd attempt, same error)

Related Issues

• [CI Failure Doctor] CI Failure Investigation - Run #37920 #18510 — Same tarball download timeout in gh-aw's own CI (actions/setup-go tarball). Recommended "vendor/cache the action tarball" but was closed as not_planned.
• Running goal: Improve and optimize time to start of coding agent and overall workflow time  #12543 — Performance issue about slow workflow startup time. Closed.

Suggested Mitigations

1. Reduce tarball size — Use .gitattributes with export-ignore to exclude tests, docs, and other non-essential files from the tarball that runners download.
2. CDN caching — Ensure the tarball endpoint is served from a CDN with proper caching headers so repeated downloads are fast.
3. Publish slim action packages — Consider publishing the actions/setup directory as a standalone action repo (or use a separate lightweight ref) rather than requiring runners to download the entire gh-aw monorepo tarball.

Impact

This is a transient but recurring issue that causes workflow failures in external consumer repos. Since the .lock.yml is auto-generated and cannot be edited, consumers have no way to add retries, caching, or workarounds at the workflow level. The only mitigation available is adding a separate retry workflow that re-runs failed jobs.

/cc @dsyme (filed #12543 on related performance concerns)

[dsyme]

Thanks, good report. We're going to move the Actions to gh-aw-actions, see #20239

This should solve this problem and improve performance

[DimaBir]

Thanks @dsyme

[pelikhan]

This is an old build, time to upgrade too.

[pelikhan]

The next release will have the pipeline to populate the action and then we should have the lightweight runtime.