From 01ad8584922b5d85292b1723cae71fa0d9b07a19 Mon Sep 17 00:00:00 2001 From: Devin Foley Date: Wed, 9 Sep 2026 14:34:45 -0700 Subject: [PATCH] ci: raise the multi-arch Docker publish timeout to 120 minutes (#13114) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The Docker workflow publishes the server images that all deployments pull, including the `sha-*` images that downstream consumers deploy > - The `build-and-push` job builds for linux/amd64 and QEMU-emulated linux/arm64, and that build now takes more than its 60 minute job timeout > - Every run dies at the timeout, and each doomed hour-long run holds the per-ref concurrency slot, so queued master pushes supersede each other and no image publishes at all > - This pull request raises the multi-arch job timeout to 120 minutes > - The benefit is that image publishing works again, with headroom for the build to grow ## Linked Issues or Issue Description Related: #12821 replaces the QEMU-emulated arm64 build with native runners — that is the durable fix for the build duration itself. This PR is the immediate unblock so images publish again while #12821 lands. No existing issue for the outage. Description follows the bug report template: **What happened?** The `docker.yml` `build-and-push` job hits its 60 minute `timeout-minutes` cap on every run. The last fully successful `docker.yml` run was September 2. Since then almost every run ends `cancelled`: the multi-arch build is killed at the timeout, and runs queued behind it are superseded by newer master pushes before they can start. The amd64-only `build-and-push-cloud` job often still succeeds inside those cancelled runs, which masked the breakage. **Expected behavior** Every master push and canary tag dispatch publishes its `sha-*` production and cloud images, and the `promote_canary_channel` job runs. **Steps to reproduce** Look at the runs of the Docker workflow on master: `gh run list --workflow docker.yml --branch master`. Nearly every run since September 5 ends `cancelled` or `failure`. Open a cancelled run: the `build-and-push` job runs for 61+ minutes and its "Build and push" step ends `cancelled` at the job timeout. The last runs that succeeded (September 2) took 39 to 54 minutes for the same job. ## What Changed - Raise `timeout-minutes` on the `build-and-push` job from 60 to 120, with a comment that explains why. The amd64-only `build-and-push-cloud` job keeps its 60 minute cap. ## Verification - `actionlint .github/workflows/docker.yml` reports no issues in this change (only pre-existing info-level shellcheck notes in untouched steps). - Compared job durations across the last successful runs (39-54 minutes) and the recent timeout kills (61+ minutes) to confirm the cap is the failure cause. - After merge, the next master push should produce a `docker.yml` run that completes with both build jobs green. ## Risks Low risk. The change only gives the existing build more time. A genuinely hung build now occupies a runner for up to 120 minutes instead of 60. The slow arm64 emulated build itself is worth a separate look (native arm runners or splitting the platforms), but that is a larger change than this outage fix. ## Model Used Claude (Anthropic) — Fable 5 (`claude-fable-5`), extended thinking, agentic tool use via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass (no code paths changed; workflow linted with actionlint) - [x] I have added or updated tests where applicable (not applicable for a CI timeout value) - [x] I have updated relevant documentation to reflect my changes (the workflow comment documents the rationale) - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --- .github/workflows/docker.yml | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/.github/workflows/docker.yml b/.github/workflows/docker.yml index adaef6e7b5..175863390b 100644 --- a/.github/workflows/docker.yml +++ b/.github/workflows/docker.yml @@ -34,7 +34,14 @@ concurrency: jobs: build-and-push: runs-on: ubuntu-latest - timeout-minutes: 60 + # The multi-arch (amd64 + QEMU-emulated arm64) production build has + # outgrown 60 minutes: the last runs to finish under the old cap took + # 39-54, and once the build crossed it every job died at the timeout. + # Each hour-long doomed run also held the per-ref concurrency slot, so + # queued master pushes superseded each other and the workflow published + # nothing at all. 120 restores headroom; the cloud job below is + # amd64-only (~10-15 minutes) and keeps its tighter cap. + timeout-minutes: 120 steps: - name: Checkout uses: actions/checkout@v7