Reduce release latency with concurrent gates and shared Go caches

.github/workflows/check.yml

@@ -40,9 +40,24 @@ jobs:
       - uses: actions/checkout@v7
         with:
           ref: ${{ inputs.ref || github.sha }}
+      - name: Select shared Go caches
+        id: source
+        run: |
+          echo "revision=$(git rev-parse HEAD)" >> "$GITHUB_OUTPUT"
+          echo "GOCACHE=$HOME/.oac/cache/go-build" >> "$GITHUB_ENV"
+          echo "GOMODCACHE=$HOME/.oac/cache/go-mod" >> "$GITHUB_ENV"
       - uses: actions/setup-go@v7
         with:
           go-version-file: go.mod
+          cache: false
+      - uses: actions/cache@v6
+        with:
+          path: |
+            ~/.oac/cache/go-build
+            ~/.oac/cache/go-mod
+          key: core-go-v1-${{ runner.os }}-${{ runner.arch }}-${{ hashFiles('**/go.mod', '**/go.sum') }}-${{ steps.source.outputs.revision }}
+          restore-keys: |
+            core-go-v1-${{ runner.os }}-${{ runner.arch }}-${{ hashFiles('**/go.mod', '**/go.sum') }}-
       - uses: actions/setup-node@v6
         with:
           node-version: '22'

.github/workflows/release.yml

@@ -32,7 +32,6 @@ jobs:
       ref: ${{ inputs.ref || github.sha }}
 
   build:
-    needs: check
     runs-on: ubuntu-22.04
     timeout-minutes: 120
     outputs:
@@ -65,9 +64,22 @@ jobs:
           df -h /
           sudo rm -rf /usr/local/lib/android /usr/share/dotnet /usr/local/.ghcup
           df -h /
+      - name: Select shared Go caches
+        run: |
+          echo "GOCACHE=$HOME/.oac/cache/go-build" >> "$GITHUB_ENV"
+          echo "GOMODCACHE=$HOME/.oac/cache/go-mod" >> "$GITHUB_ENV"
       - uses: actions/setup-go@v7
         with:
           go-version-file: go.mod
+          cache: false
+      - uses: actions/cache@v6
+        with:
+          path: |
+            ~/.oac/cache/go-build
+            ~/.oac/cache/go-mod
+          key: core-go-v1-${{ runner.os }}-${{ runner.arch }}-${{ hashFiles('**/go.mod', '**/go.sum') }}-${{ steps.source.outputs.revision }}
+          restore-keys: |
+            core-go-v1-${{ runner.os }}-${{ runner.arch }}-${{ hashFiles('**/go.mod', '**/go.sum') }}-
       - uses: actions/setup-node@v6
         with:
           node-version: '22'
@@ -76,12 +88,6 @@ jobs:
           npm install --global pnpm@10.30.3
           sudo apt-get update
           sudo apt-get install -y build-essential pkg-config libssl-dev
-      - uses: actions/cache@v6
-        with:
-          path: |
-            ~/.oac/cache/go-build
-            ~/.oac/cache/go-mod
-          key: core-release-${{ runner.os }}-${{ hashFiles('go.sum') }}
       - name: Check release metadata and prepare pinned harnesses
         run: |
           PYTHONDONTWRITEBYTECODE=1 python3 scripts/core-distribution-manifest.test.py
@@ -114,7 +120,7 @@ jobs:
 
   release:
     if: github.event_name == 'push' || inputs.draft_release
-    needs: build
+    needs: [check, build]
     runs-on: ubuntu-22.04
     permissions:
       contents: write

CONTRIBUTING.md

@@ -279,6 +279,15 @@ split oversized components before extending them. Use `internal/obs/log` for log
 
 ## Required checks
 
+Release checks and distribution builds may run concurrently against the same
+immutable source commit. Publication must depend on both successful jobs; building
+an artifact does not qualify it for release. Use the shared content-addressed Go
+compiler/module caches in CI, keyed by platform, module inputs and source revision.
+Caches may seed compilation/downloads, never replace checks or select release
+artifacts. The [maintainer guide](docs/maintainers.md#publish-a-version) owns the
+workflow, cache behavior and failure-cost tradeoff.
+
+
 Run `make check` before completion. The standalone gate includes all daemon/shared
 Go tests, Core contract/client/service tests, Core Web and TypeScript client
 checks (including fixture-only Playwright acceptance), a real dedicated PostgreSQL test

docs/maintainers.md

@@ -45,8 +45,8 @@ Tags use `vMAJOR.MINOR.PATCH`, optionally with a prerelease suffix such as
 `-rc.1` and build metadata such as `+build.1`. A prerelease suffix creates a
 GitHub prerelease. Tag creation is the maintainer's release decision.
 
-The workflow checks that exact source with the shared `make check` workflow,
-then builds the Linux amd64 Core, Web, Runtime and database images, installation
+The workflow checks that exact source with the shared `make check` workflow
+while building the Linux amd64 Core, Web, Runtime and database images, installation
 archives and versioned Runtime assets. Tag builds include the offline archive.
 It uploads the matched files as an Actions artifact and automatically publishes
 them in the same tag's GitHub Release. Downloads in the manifest refer to that
@@ -56,6 +56,23 @@ the [installation guide](getting-started/install.md#install) owns its usage.
 Images are shipped as archives; this workflow does not push an image registry.
 Publishing a Release does not change the repository's visibility.
 
+Checks and builds run concurrently, and publication requires both jobs to succeed.
+Both check out the same full commit SHA (the tag event's commit or the explicit
+manual input). A failed check never permits publication, even if its build succeeds.
+The build may consume runner time before another job fails; this trades some failed-run
+cost for shorter successful releases.
+
+Both jobs use the same Go module and compiler-cache directories under
+`~/.oac/cache/`. Cache keys include runner OS/architecture, all Go module manifests
+and checksums (including the toolchain version), and the checked-out commit.
+A dependency-matched older cache is only a compiler/download seed: Go resolves
+inputs again, and all checks still run with their existing assertions and timeouts.
+No test result, installation state or release archive is accepted from this cache.
+Main-branch checks can populate the default-branch cache for later release runs;
+GitHub's branch/tag cache visibility rules still apply. New keys are saved only
+after successful jobs; concurrent writers for the same key may retain either
+job's valid cache. Missing or evicted entries affect speed, not correctness.
+
 Build and check jobs have read-only repository permissions. Only the publication
 job receives `contents: write`. Before publication it verifies archive checksums
 and confirms that the remote lightweight or annotated tag still resolves to the