fix: install gh-aw CLI in shared token-logs-24h before fallback download#24438
fix: install gh-aw CLI in shared token-logs-24h before fallback download#24438
Conversation
The shared/token-logs-24h.md step is injected by the compiler before user-defined steps (including 'Install gh-aw CLI'). When the cache miss path runs, it calls 'gh aw logs' but gh-aw isn't installed yet, causing a silent failure that produces 0 runs. Add an inline gh-aw install check in the fallback path so the CLI is available when needed, regardless of step ordering. Fixes: github/gh-aw/actions/runs/23970804938 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Fixes a workflow ordering issue where the shared token-logs-24h step can invoke gh aw logs before the gh-aw CLI extension is installed, resulting in empty token-log data when the cache fallback path is used.
Changes:
- Add an inline
gh-awextension presence check + install in the shared 24h token logs fallback download path. - Recompile/update the 4 affected token workflows’
.lock.ymloutputs to include the shared-step change.
Show a summary per file
| File | Description |
|---|---|
.github/workflows/shared/token-logs-24h.md |
Ensures gh-aw is installed before invoking gh aw logs in the fallback path. |
.github/workflows/copilot-token-usage-analyzer.lock.yml |
Recompiled workflow embedding the updated shared token-logs step. |
.github/workflows/copilot-token-optimizer.lock.yml |
Recompiled workflow embedding the updated shared token-logs step. |
.github/workflows/claude-token-usage-analyzer.lock.yml |
Recompiled workflow embedding the updated shared token-logs step. |
.github/workflows/claude-token-optimizer.lock.yml |
Recompiled workflow embedding the updated shared token-logs step. |
Copilot's findings
Tip
Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
- Files reviewed: 5/5 changed files
- Comments generated: 1
| # Ensure gh-aw CLI is installed — this shared step runs before user-defined steps | ||
| if ! gh extension list 2>/dev/null | grep -q "github/gh-aw"; then | ||
| echo "📦 Installing gh-aw CLI extension..." | ||
| gh extension install github/gh-aw | ||
| fi |
There was a problem hiding this comment.
Because this step runs with set -euo pipefail, a transient failure in gh extension install github/gh-aw (network, GitHub host misconfiguration, permissions) will now fail the entire workflow early. The rest of the fallback path is explicitly non-fatal (gh aw logs ... || echo '{"runs":[]}'), so this introduces an inconsistent/possibly unintended hard-fail behavior. Consider handling install failure explicitly (e.g., retry and/or fall back to the previous empty-runs behavior with a clear warning), or alternatively make the whole fallback path fail loudly (remove the silent || echo on gh aw logs) so failures are detectable and consistent.
See below for a potential fix:
GH_AW_AVAILABLE=false
if gh extension list 2>/dev/null | grep -q "github/gh-aw"; then
GH_AW_AVAILABLE=true
else
echo "📦 Installing gh-aw CLI extension..."
if gh extension install github/gh-aw 2>/dev/null; then
GH_AW_AVAILABLE=true
else
echo "⚠️ Failed to install gh-aw CLI extension; continuing with empty token logs."
fi
fi
if [ "$GH_AW_AVAILABLE" = "true" ]; then
gh aw logs \
--engine copilot \
--start-date -1d \
--json \
-c 300 \
> /tmp/token-logs-copilot-raw.json 2>/dev/null || echo '{"runs":[]}' > /tmp/token-logs-copilot-raw.json
else
echo '{"runs":[]}' > /tmp/token-logs-copilot-raw.json
fi
jq '.runs // []' /tmp/token-logs-copilot-raw.json > "$TOKEN_LOGS_DIR/copilot-runs.json" 2>/dev/null || echo "[]" > "$TOKEN_LOGS_DIR/copilot-runs.json"
if [ "$GH_AW_AVAILABLE" = "true" ]; then
gh aw logs \
--engine claude \
--start-date -1d \
--json \
-c 300 \
> /tmp/token-logs-claude-raw.json 2>/dev/null || echo '{"runs":[]}' > /tmp/token-logs-claude-raw.json
else
echo '{"runs":[]}' > /tmp/token-logs-claude-raw.json
fi
Address review feedback: install failure under set -euo pipefail would hard-fail the workflow, inconsistent with the fallback-safe behavior of gh aw logs. Use GH_AW_AVAILABLE flag to gate log downloads and fall back to empty runs with a warning if install fails. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
lpcox
left a comment
There was a problem hiding this comment.
Applied the suggested pattern — install failure is now non-fatal using a GH_AW_AVAILABLE flag. When install fails, it logs a warning and falls back to empty runs, consistent with the || echo behavior on gh aw logs.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Problem
The Copilot Token Usage Analyzer run 23970804938 completed successfully but produced 0 runs — no report was created.
Root cause: The
shared/token-logs-24h.mdshared component is injected by the compiler as step 6, before the user-defined "Install gh-aw CLI" step (step 7). When the Token Logs Fetch cache is stale or unavailable, the fallback path callsgh aw logs— butgh-awisn't installed yet. The command fails silently (2>/dev/null || echo '{"runs":[]}') and writes empty data.Execution trace:
Fix
Add an inline
gh-awinstall check in the shared component's fallback path:This ensures
gh aw logshas the CLI available regardless of step ordering.Files Changed
.github/workflows/shared/token-logs-24h.md— add gh-aw install before fallback download.lock.ymlfiles (recompiled)Testing