From 892681f78ddd629c8ea6b9e22a9f25a13eff3fd2 Mon Sep 17 00:00:00 2001 From: Dave Page Date: Wed, 16 Sep 2026 15:48:23 +0100 Subject: [PATCH] Queue rather than cancel concurrent macOS signing builds Copied from the QA builds without thinking, where cancelling an in-flight run on a new push is exactly right: the tip is what matters and a superseded build is wasted effort. A signing build is not that. Cancelling one throws away forty minutes of work, and worse, it can abandon a notarisation already submitted to Apple, leaving a request in their queue for a build nobody will ever collect. The Windows snapshot already queues rather than cancels, for the related reason that there is one hardware token, so this brings the two into line. Found by cancelling my own in-flight Intel notarisation with an unrelated push. --- .github/workflows/snapshot-macos.yml | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/.github/workflows/snapshot-macos.yml b/.github/workflows/snapshot-macos.yml index df9b406b7..fb7df046d 100644 --- a/.github/workflows/snapshot-macos.yml +++ b/.github/workflows/snapshot-macos.yml @@ -29,8 +29,12 @@ on: - 'pkg/mac/**' concurrency: + # Not cancel-in-progress, unlike the QA builds. Cancelling a signing build + # partway through wastes forty minutes of work and, worse, can abandon a + # notarisation already submitted to Apple, leaving a request sitting in their + # queue for a build nobody will collect. Queue instead. group: '${{ github.workflow }} @ ${{ github.ref }}' - cancel-in-progress: true + cancel-in-progress: false permissions: contents: read