Skip to content

fix(ci): agents.yml sets timeout-minutes on a reusable-workflow caller job — workflow fails at startup, and check:workflows cannot see it #1481

Closed

Description

@dezren39

fix(ci): agents.yml sets timeout-minutes on a reusable-workflow caller job — workflow fails at startup, and check:workflows cannot see it

Evidence (verified on main eeebf4143d, 2026-11-02)

.github/workflows/agents.yml:44-46 — the repo's only job-level reusable-workflow call now carries a key GitHub does not allow on a caller job:

jobs:
  scheduled:
    uses: developing-today/code/.github/workflows/pm-scheduled.yml@main
    timeout-minutes: 60

Added by commit fb06892c2d ("ci: add job timeouts to agents.yml", PR #1480, merged as eeebf4143d minutes before this filing).

GitHub's reusable-workflow reference is explicit about the caller job's allowed keywords: "When you call a reusable workflow, you can only use the following keywords in the job containing the call: jobs.<job_id>.name, uses, with, secrets, strategy, needs, if, concurrency, permissions, cache-mode" (docs.github.com, "Reusing workflow configurations"). timeout-minutes is not among them — a caller job has no steps of its own, so there is nothing for it to time out; the called workflow owns its jobs' timeouts.

Observed behavior since the change:

  • Actions run 41566885724 (push, head eeebf4143d, .github/workflows/agents.yml): conclusion failure, and the run's jobs list is empty — the workflow never started a job. gh run view reports: "This run likely failed because of a workflow file issue."
  • The scheduled agent dispatches this workflow exists for (bolt / palette / suggestions slots, per the file's own header) therefore do not run at all on this revision.

The repo's own gate cannot catch this class:

  • bun run check:workflows on the same main exits 0 ("All 29 workflows … follow the workflow policies").
  • script/check-workflows.ts (workflowViolations) skips caller jobs entirely: if ("uses" in job) continue. Its header even documents why the exemption exists — "the caller cannot set timeout-minutes on such a job" — but the gate only exempts caller jobs from the timeout requirement; it never flags a forbidden key placed on one. test.yml runs this gate on every push to main, so CI is green on a workflow file GitHub rejects at startup.
  • agents.yml is the only workflow in the repo with a job-level uses: (grep over .github/workflows/*.yml), so today this blind spot has exactly one live instance — this one.

Related: #1406 (the workflow-policy gate this extends), #970 (prior startup-failure class in this repo's workflows), #61 / #1326 / #1184 (the timeout-minutes convention that motivated the change — it applies to jobs with steps, not to caller jobs).

Why it matters

A well-intentioned timeout sweep silently disabled the repo's scheduled-agent dispatcher: the workflow fails validation before any job exists, so there is no failing job to alert on — the runs just read "failure" with an empty jobs list. And the policy gate built in #1406 to keep workflow files valid-by-construction is blind to exactly the key-placement error that caused it, so the same mistake can recur in any future caller workflow.

Acceptance criteria

  • .github/workflows/agents.yml: the scheduled caller job no longer sets timeout-minutes (or any other key outside GitHub's caller-job allowlist); if a dispatch timeout is wanted, it is set on the jobs inside the called workflow (developing-today/code pm-scheduled.yml), not here.
  • A workflow_dispatch (or push) run of agents.yml on the fixed revision starts jobs instead of failing at startup with an empty jobs list.
  • script/check-workflows.ts flags non-allowlisted keys on reusable-workflow caller jobs (at minimum timeout-minutes, runs-on, steps, env, defaults), with coverage in script/check-workflows.test.ts; the gate fails on the pre-fix agents.yml and passes on the fixed tree.
  • bun run check:workflows passes on the fixed tree, and no other workflow's caller jobs (if any appear) regress.

Activity

  1. added
    kind/bugSomething isn't working (prefixed form of the classic bug label)
    kind/ciCI/CD pipelines, workflows, and build automation
    task/triageQueue packet kind: verify, reproduce, and route this item
    source/creatorFiled by the new-issue-creator job
    priority/highImportant and time-sensitive
    queue/queuedHas a queued task in the Supabase agent queue
    area/ciCI, workflows, and build infrastructure
    app/scriptPackage: script (pkgs/ or apps/ in this repo)
    effort/sSmall: expected under 2 hours of work
    on Nov 3, 2026
  2. dezren39 commented on Nov 3, 2026

    @dezren39
    Author

    🤖 Agent note · filed

    • Agent: new-issue-creator job (new-issue-creator-opencode)
    • Session / ID: cron new-issue-creator-opencode, run 2026-11-02 20:35 CST
    • Found via: filed this run
    • Task: Filed this issue — agents.yml:46 sets timeout-minutes on a reusable-workflow caller job (added by PR ci: add timeout-minutes to jobs that lacked one #1480, commit fb06892); GitHub's caller-job allowlist excludes it, run 41566885724 on main eeebf41 failed at startup with an empty jobs list, and check:workflows exits 0 because it skips uses-jobs entirely. Enqueued as a repo-task/v1 packet on repo-health-opencode-pilot.
    • Expectation: effort/s — remove the forbidden key (any dispatch timeout belongs in the called workflow) and extend check:workflows to flag non-allowlisted keys on caller jobs, with tests.
    • Links: packet packet-opencode-1481.json (hidden_files, keep-the-four-repos-healthy goal)
  3. dezren39 commented on Nov 3, 2026

    @dezren39
    Author

    Main-CI watch (fleet): reusing this issue for the newest main-branch failure of .github/workflows/agents.yml instead of filing a duplicate.

    Filed by main-ci-failure-fix-trigger (fleet). One fix track per failing workflow; duplicates are suppressed until this issue closes.

  4. dezren39 commented on Nov 3, 2026

    @dezren39
    Author

    🤖 Agent note · filed

  5. dezren39 commented on Nov 3, 2026

    @dezren39
    Author

    Progress update (queue task 6729): verified run 41566885724 is the cited main push run for agents.yml, concluded failure with zero jobs; the worktree is clean at the failing head eeebf4143d6c227d3d5ecd728e94e8cbf1b33a6f. I’m extending the workflow policy checker and tests, and removing the unsupported caller-job timeout. The called workflow lives in developing-today/code; I will not change its internals here. The queue checkpoint helper is not at the documented ~/tools/repo-queue.py path, so I’m locating it.

  6. dezren39 commented on Nov 3, 2026

    @dezren39
    Author

    🤖 Agent note · dispatched

    • Agent: main-ci-failure-fix-trigger (fleet)
    • Session / ID: ses_e5e60ad8153ffeu39b460zEuG4 ↔ queue task 6729 ↔ issue fix(ci): agents.yml sets timeout-minutes on a reusable-workflow caller job — workflow fails at startup, and check:workflows cannot see it #1481
    • Pool: opencode-route/workhorse (Workhorse, pooled route; fresh quota read 2026-11-03T02:46Z: meta 100% 5h (resets ~03:47Z) / 69% weekly, opencode-go 0% 5h / 0% weekly, codex 99% weekly — route not walled as a whole (opencode-go headroom), capacity 5/30 unfinished roots)
    • Worktree / branch: laptop ~/git/fleet/6729-1481-ci-agents, branch queue/6729-1481-ci-agents (from origin/main eeebf41, the failing run's head)
    • Task: Triage/fix the zero-job startup failure of .github/workflows/agents.yml — run https://github.com/developing-today/opencode/actions/runs/41566885724 (this issue's packet, enqueued by new-issue-creator as task 6729, was claimed by this trigger and dispatched; the trigger's own enqueue deduped to task 6729 — no duplicate task)
    • Engagement verified: assistant messages in the session confirm run 41566885724's startup failure, the clean worktree at eeebf41, and are reading .github/workflows/agents.yml and script/check-workflows.ts / its tests.
    • Expectation: done when a main-branch run of .github/workflows/agents.yml completes with conclusion success after the fix merges, verified against the run log.
  7. dezren39 commented on Nov 3, 2026

    @dezren39
    Author

    Progress update (queue task 6729): check:workflows now fails against the original agents.yml with a specific reusable-workflow-caller-keys violation for scheduled.timeout-minutes, demonstrating the previous blind spot is closed. Removed that caller key; the focused test file passes (18 tests) and bun run check:workflows passes across all 29 workflows. Added cases for timeout-minutes, runs-on, steps, env, and defaults, plus an allowlisted-caller case. The task helper was present at /home/user/hatch/tools/repo-queue.py rather than ~/tools/repo-queue.py; I’m checkpointing there, then will review, commit, push, and open a PR without merging.

  8. dezren39 commented on Nov 3, 2026

    @dezren39
    Author

    Update: PR #1482 is open at #1482 (base main, branch queue/6729-1481-ci-agents). The workflow timeout key is removed and the reusable-caller allowlist check plus tests are included. It is not merged; I’m parking task 6729 with the PR link while CI/review and the post-merge main run remain outstanding.

  9. added
    queue/parkedQueue task is parked (waiting on CI, time, or an event)
    work/assignedAn agent holds this item via the queue (claimed task)
    and removed
    queue/queuedHas a queued task in the Supabase agent queue
    on Nov 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    app/scriptPackage: script (pkgs/ or apps/ in this repo)area/ciCI, workflows, and build infrastructureeffort/sSmall: expected under 2 hours of workkind/bugSomething isn't working (prefixed form of the classic bug label)kind/ciCI/CD pipelines, workflows, and build automationpriority/highImportant and time-sensitivequeue/parkedQueue task is parked (waiting on CI, time, or an event)source/creatorFiled by the new-issue-creator jobstatus/in-progressActively being workedtask/triageQueue packet kind: verify, reproduce, and route this itemwork/assignedAn agent holds this item via the queue (claimed task)

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions