Dockerfile.runtime is a thin runtime-only image (debian:trixie-slim +
ca-certificates + the keploy binary + entrypoint.sh). It expects a
prebuilt binary at dist/keploy-linux-$TARGETARCH/keploy in the build
context, so builds are COPY-only (~10s) instead of going through an
in-container 'go build'. Multi-arch uses BuildKit's TARGETARCH.

The main Dockerfile is left alone so external users who want to build
from source still get a self-contained image.

update-docker.sh and update-docker-ci.sh existed only to sed the main
Dockerfile for -race / SSH mounts / GOPRIVATE at CI time. Those
mutations move upstream into the binary-build step (where -race /
CGO / the private module access already live), so the scripts become
dead code.

Signed-off-by: Shubham Jain <shubhamkjain@outlook.com>

Principal-review follow-ups on #4097. No behavioural change on the
happy path; hardening for edge cases.

* download-image/action.yml (Unix): anchor the 'Loaded image: '
  regex with a leading caret and trailing space so the
  'Loaded image ID: sha256:...' variant (emitted when the tarball
  has no RepoTags) can't silently retag a digest. NR==1 + exit
  keeps selection deterministic without a 'head -n1' that could
  SIGPIPE awk under pipefail. On miss, log the first lines of
  docker load output so failures are debuggable.

* download-image/action.yml (Windows): anchor ^Loaded image: and
  .Trim() the capture so the trailing CR from docker CLI's CRLF
  line endings doesn't end up in the retag reference (docker tag
  rejects 'keploy/keploy:ci\r' as invalid format). Also log full
  docker load output on miss.

* release.yml: replace 'ls -d ... | head -n1' with an explicit
  shell nullglob array so an empty dist/ layout after a
  goreleaser change fails loudly instead of 'cp'-ing from an
  empty string under set -e.

* prepare_and_run.yml: bump image-artifact retention from 1 day
  to 7 days. Re-running a failed platform gate more than 24h
  after the original workflow run was hitting 'artifact not
  found' because the upstream build jobs were cached success.
  Two tarballs per run is cheap.

* prepare_and_run.yml: document the shared-concurrency-group
  trade-off so a future reader understands why cleanup jobs
  can be concurrency-cancelled across all three OS legs
  simultaneously rather than per-workflow.

* download-binary/action.yml: broaden the 'src' input description
  — 'build | latest' was stale after the build-darwin rename.

Signed-off-by: Shubham Jain <shubhamkjain@outlook.com>

…review)

Addresses Copilot review on b6db664 and the go-memory-load /
proxy-stress-test regressions that surfaced in the same run.

1. Docker images are now built from non-race binaries.

   Investigation: on the PR's CI run, 'run_golang_docker / go-memory-load'
   failed with 'Keploy container exceeded 250.00 MiB during record',
   and 'run_golang_docker / proxy-stress-test' failed with
   'WARNING: DATA RACE / FAIL: Data race during replay'. Both are
   caused by the refactor switching the linux/amd64 docker image
   from the historically non-race binary to the 'build' race
   artifact. The old update-docker.sh had a broken add_race_flag
   BRE regex ('^(RUN\s+go\s+build)\s' did not match
   'RUN GOMAXPROCS=2 go build ...') that silently failed to insert
   -race into the in-container go build; the effective prior
   behaviour was a non-race linux docker image. Restore parity:

     * build-linux-arm64 now builds a non-race binary, uploaded
       as build-no-race-linux-arm64 (makes arm64 consistent with
       amd64 — the arm64 docker image is the only consumer).
     * build-docker-image-amd64 downloads build-no-race instead
       of build.
     * build-docker-image-arm64 downloads build-no-race-linux-arm64.

   Race-detection coverage is preserved at the native-linux level
   (run_golang_linux consumes the race-enabled 'build' artifact).
   Docker coverage is about integration semantics, not data-race
   scrutiny, and inflating the agent's memory baseline by the
   race runtime broke go-memory-load's calibrated threshold.

   Note: the 'DATA RACE during replay' surfaced by this PR is a
   real pre-existing bug in keploy's replay path that was masked
   by the broken CI script. Filing as a follow-up issue — out of
   scope for this CI refactor.

2. download-image Windows step switches shell: pwsh -> shell: powershell.

   Windows PowerShell 5.1 is always preinstalled on Windows runners;
   pwsh (7) is not. The build-windows-amd64 job has a Bootstrap
   PowerShell step that repairs missing pwsh, but
   pull-docker-image-windows (which invokes this composite action)
   has no such bootstrap, so a fleet runner without pwsh would
   fail the image-load step with 'pwsh: command not found'. All
   cmdlets used in the Windows branch (Join-Path, Test-Path,
   Get-ChildItem, Select-String, [Environment]::NewLine, .Trim(),
   [string]::IsNullOrWhiteSpace) are 5.1-compatible, so the floor
   is free.

3. CI_CONTRIBUTING.md: Key files table row for prepare_and_run.yml
   updated — said 'builds + pushes the one Docker image' but the
   workflow now uploads image.tar artifacts (no registry push).

Signed-off-by: Shubham Jain <shubhamkjain@outlook.com>

Fixes the data race surfaced by this PR's -race-enabled docker image
under proxy-stress-test (record_build_replay_build):

  WARNING: DATA RACE
  Read/Write at 0x... by goroutine <N>:
    go.keploy.io/server/v3/pkg/agent/proxy/integrations/http.(*HTTP).updateMock()
    pkg/agent/proxy/integrations/http/match.go:723 / :724 / :725
    pkg/agent/proxy/integrations/http.(*HTTP).decodeHTTP.func1()
    pkg/agent/proxy/integrations/http.(*HTTP).MockOutgoing()
    pkg/agent/proxy.(*Proxy).handleConnection()
    pkg/agent/proxy.(*Proxy).start.func4()

Root cause: updateMock() received matchedMock as a pointer handed
out of the shared MockMemDb. Two concurrent HTTP requests that
match the same session-lifetime mock receive the SAME pointer, so
the in-place mutations

    matchedMock.TestModeInfo.IsFiltered = false
    matchedMock.TestModeInfo.SortOrder  = pkg.GetNextSortNum()

race against another goroutine's struct-copy read on the same
memory (matched by the 'originalMatchedMock := *matchedMock' line
one above). Multiple distinct DATA RACE reports in the CI log all
point at these three consecutive lines under decode.go:165's
per-request goroutine fan-out.

Fix: build a fresh shallow copy of the matched mock, mutate the
copy, and pass (old=matchedMock, new=&updatedMock) to
MockManager.UpdateUnFilteredMock. The mock DB already serialises
the tree swap under treesMu; the only missing piece was callers
not racing on the caller-visible pointer before handing it in.
Escape analysis heap-allocates the copy when taking its address,
so pool-stored pointers remain valid after return.

Applied to every site with this anti-pattern:
  * pkg/agent/proxy/integrations/http/match.go         (the one CI caught)
  * pkg/agent/proxy/integrations/mysql/replayer/match.go
  * pkg/agent/proxy/integrations/generic/match.go      (two call sites)

pkg/util.go:filterByTimeStamp already does mock.DeepCopy() up front
specifically to avoid this class of race (see the comment at line
2577) — left untouched.

Local verification: go test -race ./pkg/agent/proxy/integrations/http/
passes (1.8s). The full CI will exercise the docker replay path
under -race via the race-enabled 'build' artifact consumed by the
native golang_linux job — if the race resurfaces elsewhere, the
pattern above is the one to look for.

Signed-off-by: Shubham Jain <shubhamkjain@outlook.com>

Copilot review follow-ups on 9a47372.

1. .github/actions/download-image/action.yml:
   Previously the failure path did `$(docker load -i "$TAR" 2>&1 | head -n5)`
   inside the ::error:: message — re-importing the tarball a second time
   AND piping into head, which under set -euo pipefail can SIGPIPE
   docker load and abort the step before the error line is emitted.
   Capture docker load output once into LOAD_OUTPUT, check the exit
   code up front (so a genuine load failure surfaces with the output
   as diagnostic), and reuse the same buffer to parse the loaded
   image tag and to populate the 'no RepoTags' diagnostic. tr 'n;'
   flattens multi-line output for the ::error:: marker.

2. .github/CI_CONTRIBUTING.md:
   The composite action tags with ghcr.io/keploy/keploy:v${{ inputs.version }},
   defaulting to 3-dev — several workflows (e.g. golang_docker_macos,
   golang_docker_windows, pull-docker-image-*) pass
   version: ${{ github.sha }}, producing v<sha> tags. Two mentions in
   the CI contributing guide hard-coded 'v3-dev' and would mislead
   contributors writing new docker-based samples. Both now say
   'v<version> (defaults to 3-dev; callers may override)'.

Signed-off-by: Shubham Jain <shubhamkjain@outlook.com>

…ption

Copilot review follow-ups on 16d2f75.

1. download-image/action.yml (Unix loader):
   awk pattern was '/^Loaded image: / && NR==1' — restricted the match
   to the first *output line*, not the first 'Loaded image:' line.
   If docker load ever prints a status line before the tag line
   (some daemon versions do), LOADED ends up empty and the action
   fails despite a successful load. Drop the NR==1 guard; 'exit'
   still keeps selection deterministic by stopping on the first
   matching line regardless of where it appears in the output.

2. download-image/action.yml (Windows loader):
   'docker load -i $tar' did not capture stderr and did not check
   $LASTEXITCODE. On a genuine load failure, stderr was lost and
   $loadOutput stayed empty, so the step fell through to the 'no
   tagged image' branch with useless diagnostics. Capture 2>&1
   into $loadOutput and fail fast on non-zero $LASTEXITCODE so
   the real docker error output appears in the ::error::. Same
   pattern applied to the existing 'no RepoTags' and 'empty
   reference' branches so all three diagnostic paths use
   Out-String on the real captured output.

3. download-binary/action.yml:
   The src input description still read 'Name of a binary artifact
   ... (e.g. build, build-no-race, build-darwin, latest).' which
   suggested Windows artifacts like 'build-windows' were acceptable.
   The composite action hardcodes chmod +x on ${src}/keploy and
   assumes a Unix binary — passing a Windows artifact would fail
   because the file is keploy.exe and chmod +x isn't meaningful.
   Tighten the description to explicitly call out Unix-only and
   point Windows consumers at actions/download-artifact@v4 directly
   (which is what golang_docker_windows.yml and
   golang_native_windows.yml already do).

Signed-off-by: Shubham Jain <shubhamkjain@outlook.com>

Five review items, all addressed with prod-grade solutions:

1. release.yml — Setup QEMU explicitly before buildx multi-arch build.
   Dockerfile.runtime has RUN steps (apt-get + sed/chmod), and the
   linux/arm64 leg runs under emulation on ubuntu-latest runners.
   Prior flow happened to work because ubuntu-latest preinstalls
   binfmt_misc handlers, but relying on implicit runner defaults is
   fragile. Add docker/setup-qemu-action@v3 with a header comment
   clarifying that qemu handles the base-image bootstrap only — the
   keploy binary is still a native prebuilt arm64 artifact, so qemu
   scope is bounded to one apt-get layer (not a go-build cross
   compile, which was the original performance goal).

2. http/match_test.go — Add unit coverage for updateMock's
   no-mutation invariant. Two tests:
     * TestUpdateMock_DoesNotMutatePoolPointer: session-lifetime
       path. Asserts matchedMock.TestModeInfo.IsFiltered /
       SortOrder are UNCHANGED after updateMock, that
       UpdateUnFilteredMock received the pool pointer as 'old',
       and a distinct (non-aliased) *Mock with updated
       TestModeInfo as 'new'.
     * TestUpdateMock_PerTestPrefersDelete: per-test path.
       Asserts DeleteFilteredMock is called with the original
       mock and UpdateUnFilteredMock is NOT invoked on the
       success path.
   Both guard against future regressions that would reintroduce
   the in-place mutation the race-fix commit removed. mockMemDb
   gets spy fields for old/new args + configurable return values.

3. prepare_and_run.yml — Fork-guard build-docker-image-amd64.
   Every linux docker consumer (run_*_docker) is already fork-
   guarded via the reusable workflow's inner 'if:'. Without a
   guard on the producer, fork PRs still run the docker image
   build + artifact upload even though no job will consume it.
   Add the same condition to match build-docker-image-arm64.

4-5. prepare_and_run.yml — Drop redundant docker-image pre-load
   from pull-docker-image-macos and pull-docker-image-windows.
   Each downstream docker test job already runs the download-image
   composite action (actions/download-artifact + docker load), so
   the pre-load step just duplicated artifact download + docker
   load on the self-hosted runner. Rename the jobs to precheck-*
   to reflect their remaining purpose: per-OS setup (lock file,
   keychain unlock on macOS; git isolation + Docker readiness
   check on Windows) that must fail fast BEFORE the parallel
   test matrix spins up. needs: chain for downstream tests
   (run_*_docker_*) still includes build-docker-image-* directly
   so the artifact is ready when tests load it. Gate jobs
   (gate_macos, gate_windows) updated to reference the new job
   ids.

Verified:
  * go test -race -run TestUpdateMock ./pkg/agent/proxy/integrations/http/
    → both tests PASS
  * go build ./... clean
  * YAML syntax valid for prepare_and_run.yml and release.yml
Signed-off-by: Shubham Jain <shubhamkjain@outlook.com>

Copilot review follow-ups on 75e8260.

1. release.yml — Refactor build-docker into per-arch matrix over
   [ubuntu-latest / ubuntu-24.04-arm] with push-by-digest, plus a
   downstream build-docker-manifest job that stitches the digests
   into the public multi-arch manifest list via docker buildx
   imagetools create and cosign-signs the resulting manifest.

   This replaces the prior single-job multi-arch build that required
   docker/setup-qemu-action for the linux/arm64 leg's
   Dockerfile.runtime RUN steps (apt-get + sed/chmod). Each arch
   now builds natively on its own runner, making the PR
   description's 'no qemu anywhere in the release pipeline' claim
   actually true — not just for the goreleaser binary cross
   compile, but for the base-image bootstrap too. Wall-clock is
   about the same (both legs run in parallel; amd64 was never
   under qemu; arm64 shaves ~1 min of emulated apt-get).

   docker/metadata-action runs in both the per-arch legs (for
   labels) and in the manifest job (for tags); setting tags on the
   per-arch build would push single-arch images by tag, defeating
   the push-by-digest flow. Metadata is deterministic across runs
   for a given ref so the tags the manifest job computes match
   what the legs would have produced.

   mark-latest's needs: list updated from build-docker to
   build-docker-manifest since that's the new final-tag job.

2. prepare_and_run.yml — Fix stale build-and-upload header comment.
   Said 'build = race, consumed by most linux docker tests AND by
   the linux/amd64 docker image' — but the linux/amd64 docker image
   now uses build-no-race (see build-docker-image-amd64 download
   step). Updated to reflect build = native linux tests, build-no-race
   = docker image, with a note about why (race-runtime memory
   baseline vs go-memory-load's calibrated threshold).

Signed-off-by: Shubham Jain <shubhamkjain@outlook.com>