From 6ce6b6da1059570140f95d0923e2e7faf4e127a7 Mon Sep 17 00:00:00 2001
From: claude <no-reply+claude@chaosbit.de>
Date: Wed, 9 Sep 2026 08:25:00 +0000
Subject: [PATCH] Probe: does this Gitea honour concurrency +
 cancel-in-progress?

bit's versionCode design on weblib-viewer#15 would rest on a later commit
cancelling an earlier build for the same minute. That is a concurrency
group with cancel-in-progress, which is standard -- but this instance has
already contradicted four reasonable assumptions about Gitea Actions, so
it is measured rather than assumed.

Job logs are unreadable here (they 500), so the answer is carried by the
run states in /actions/tasks: two successes means the group was ignored, a
cancelled first run means it works, and a queued second run means it is
honoured but serialises instead of cancelling.

Refs weblib/weblib-viewer#15.

Co-authored-by: bit <bit@das-labor.org>
---
 .gitea/workflows/probe-concurrency.yml | 38 ++++++++++++++++++++++++++
 marker.txt                             |  1 +
 2 files changed, 39 insertions(+)
 create mode 100644 .gitea/workflows/probe-concurrency.yml
 create mode 100644 marker.txt

diff --git a/.gitea/workflows/probe-concurrency.yml b/.gitea/workflows/probe-concurrency.yml
new file mode 100644
index 0000000..fa8dcd9
--- /dev/null
+++ b/.gitea/workflows/probe-concurrency.yml
@@ -0,0 +1,38 @@
+# Throwaway probe, deleted once it has answered. weblib-viewer#15.
+#
+# Question: does Gitea 1.25.2 honour `concurrency:` with cancel-in-progress?
+# bit's versionCode design would rest on it — a later commit in the same
+# minute cancels the earlier build, so the two never both publish.
+#
+# This instance has already contradicted four reasonable assumptions (no
+# environments, owner-gated /actions/runs, artifacts invisible in both
+# listings, job logs 500), so this is measured rather than read off the docs.
+#
+# How to read the result, given job logs are unreadable here: push twice in
+# quick succession. Then in /actions/tasks,
+#
+#   both runs "success"            -> concurrency is IGNORED, both ran
+#   first "failure"/"cancelled"    -> cancel-in-progress WORKS
+#   first finishes, second waits   -> honoured, but queues instead of cancels
+#
+# The sleep is long enough that the second push lands while the first is
+# still running; without it both would finish before they could overlap.
+name: probe concurrency
+
+on:
+  push:
+    branches: [probe/concurrency]
+
+concurrency:
+  group: probe-concurrency
+  cancel-in-progress: true
+
+jobs:
+  slow:
+    runs-on: nix
+    steps:
+      - name: occupy the group for a while
+        run: |
+          echo "start $(date -u +%H:%M:%S) sha=$GITHUB_SHA"
+          sleep 120
+          echo "end   $(date -u +%H:%M:%S) sha=$GITHUB_SHA"
diff --git a/marker.txt b/marker.txt
new file mode 100644
index 0000000..740bca8
--- /dev/null
+++ b/marker.txt
@@ -0,0 +1 @@
+run 1