Prewarm Go dependencies for TW tasks

[mohit-raghavendra]

Summary

• remove docker_image from all 38 TW Go task configs so Harbor builds each task Dockerfile
• download each repository pinned Go module graph while the image build has network access
• force agent and verifier runtime dependency resolution offline with GOPROXY=off and GOSUMDB=off
• install the task Go 1.23.1 toolchain in the one Grafana image that does not consistently include Go

Validation

• ran all 38 affected tasks in three batches (5 + 20 + 13): 38 completed, 0 errored, 0 retries
• confirmed the result task set exactly matches the 38 task directories in this PR
• validated 38 Dockerfile/task.toml pairs and confirmed each task.toml only removes docker_image
• git diff --check

Greptile Summary

This PR prewarns Go dependencies for all 38 TW Go tasks by moving from a pre-built Harbor image (referenced via docker_image in task.toml) to a built-on-demand Dockerfile that runs go mod download at image-build time and then forces offline resolution at runtime with GOPROXY=off and GOSUMDB=off.

• 37 tasks: each Dockerfile gains WORKDIR /app, RUN go mod download, and ENV GOPROXY=off GOSUMDB=off; each task.toml drops the docker_image line to trigger a Harbor build.
• 1 task (grafana_grafana): extends the pattern with a conditional Go 1.23.1 installation from go.dev/dl/, patching the PATH for both the RUN step and the final environment — this is the only file with meaningful divergence from the template.
• All 38 task.toml files: the sole change in each is removing docker_image; no other configuration fields are touched.

Confidence Score: 4/5

Safe to merge. The 37 standard Dockerfiles are straightforward and the approach is validated by the 38-task test run described in the PR.

The change is mechanically consistent across all 38 tasks and the author has run a full validation sweep. The only non-trivial file is the Grafana grafana Dockerfile, which has three minor hardening gaps: no SHA-256 check on the downloaded Go binary, the architecture is hardcoded to amd64, and the version guard doesn't enforce the specific 1.23.1 release if Go is already present in the image. None of these would break existing runs, but they are worth closing before the pattern is reused or the image is built on different hardware.

data/tw/task-6902ef3ab97fe23e2ad27209/environment/Dockerfile is the only file that warrants a second look; all other Dockerfiles and task.tomls are templated and consistent.

Important Files Changed

Filename	Overview
data/tw/task-6902ef3ab97fe23e2ad27209/environment/Dockerfile	Only file with non-trivial logic: conditionally installs Go 1.23.1 from go.dev if absent, then runs go mod download. Has three concerns: no SHA-256 verification on the downloaded tarball, architecture hard-coded to linux-amd64, and the version-presence guard may silently use the wrong Go version.
data/tw/task-6902ef3ab97fe23e2ad271f9/environment/Dockerfile	Representative of 37 tasks: adds WORKDIR /app, go mod download, and GOPROXY=off GOSUMDB=off. Straightforward and correct.
data/tw/task-6902ef3ab97fe23e2ad271f9/task.toml	Removes docker_image field so Harbor builds from the Dockerfile. Representative of all 38 task.toml changes; no other fields modified.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Harbor image build triggered\nby absence of docker_image in task.toml] --> B{Is this grafana_grafana?}
    B -- No --> C[FROM pre-built base image\nWORKDIR /app]
    B -- Yes --> D[FROM pre-built base image\nWORKDIR /app]
    D --> E{go already on PATH?}
    E -- No --> F[apt-get install wget ca-certs\nwget go1.23.1.linux-amd64.tar.gz\ntar -C /usr/local -xzf\nPATH prepended]
    E -- Yes --> G[Skip install, use existing go]
    F --> H[go mod download]
    G --> H
    C --> I[go mod download]
    H --> J[ENV GOPROXY=off\nGOSUMDB=off\nPATH patched]
    I --> K[ENV GOPROXY=off\nGOSUMDB=off]
    J --> L[Agent / verifier runs\nAll deps resolved from image cache only]
    K --> L

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
    A[Harbor image build triggered\nby absence of docker_image in task.toml] --> B{Is this grafana_grafana?}
    B -- No --> C[FROM pre-built base image\nWORKDIR /app]
    B -- Yes --> D[FROM pre-built base image\nWORKDIR /app]
    D --> E{go already on PATH?}
    E -- No --> F[apt-get install wget ca-certs\nwget go1.23.1.linux-amd64.tar.gz\ntar -C /usr/local -xzf\nPATH prepended]
    E -- Yes --> G[Skip install, use existing go]
    F --> H[go mod download]
    G --> H
    C --> I[go mod download]
    H --> J[ENV GOPROXY=off\nGOSUMDB=off\nPATH patched]
    I --> K[ENV GOPROXY=off\nGOSUMDB=off]
    J --> L[Agent / verifier runs\nAll deps resolved from image cache only]
    K --> L

Loading

Prompt To Fix All With AI

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
data/tw/task-6902ef3ab97fe23e2ad27209/environment/Dockerfile:11-13
**No checksum verification on Go tarball download**

The tarball is fetched from `go.dev/dl/` over HTTPS and extracted immediately without verifying a SHA-256 digest against a known-good value. A compromised CDN response or a partial download would be extracted silently; `tar` accepts partial archives as long as the stream doesn't terminate mid-block. The official Go download page publishes SHA-256 digests for every release — adding a `sha256sum --check` step before `tar` would close this gap and is a standard practice in secure Dockerfiles that fetch remote binaries.

### Issue 2 of 3
data/tw/task-6902ef3ab97fe23e2ad27209/environment/Dockerfile:8-16
**Conditional install may silently use wrong Go version**

The guard `if ! command -v go >/dev/null 2>&1` skips installation whenever any `go` binary is on the PATH — regardless of version. The comment states the intent is to install "the version used by the task's test runner" (1.23.1), but if the base image happens to ship Go at a different version the condition will pass, `go mod download` will run with that version, and the `ENV PATH` extension will simply prepend the non-existent `/usr/local/go/bin` without error. The baked module cache may then be incompatible with whatever `go` the agent or verifier actually resolves at runtime. Pinning the check to the exact version string (e.g. `go version | grep -q go1.23.1`) would make this intent explicit and enforceable.

### Issue 3 of 3
data/tw/task-6902ef3ab97fe23e2ad27209/environment/Dockerfile:11
**Architecture hard-coded to `linux-amd64`**

The tarball name `go1.23.1.linux-amd64.tar.gz` will install the wrong binary — or fail at runtime under non-emulated execution — if the Docker build ever runs on an ARM64 host. The 37 other tasks rely on whatever Go the base image ships (which is presumably already arch-appropriate), but this task installs from a fixed URL. Consider using `$(dpkg --print-architecture)` or `$(uname -m)` to derive the correct suffix, or document the assumption that build infrastructure is always x86-64.

_{Reviews (1): Last reviewed commit: "Prewarm Go dependencies for TW tasks" | Re-trigger Greptile}

Greptile also left 3 inline comments on this PR.

[greptile-apps]

No checksum verification on Go tarball download

The tarball is fetched from go.dev/dl/ over HTTPS and extracted immediately without verifying a SHA-256 digest against a known-good value. A compromised CDN response or a partial download would be extracted silently; tar accepts partial archives as long as the stream doesn't terminate mid-block. The official Go download page publishes SHA-256 digests for every release — adding a sha256sum --check step before tar would close this gap and is a standard practice in secure Dockerfiles that fetch remote binaries.

Prompt To Fix With AI

This is a comment left during a code review.
Path: data/tw/task-6902ef3ab97fe23e2ad27209/environment/Dockerfile
Line: 11-13

Comment:
**No checksum verification on Go tarball download**

The tarball is fetched from `go.dev/dl/` over HTTPS and extracted immediately without verifying a SHA-256 digest against a known-good value. A compromised CDN response or a partial download would be extracted silently; `tar` accepts partial archives as long as the stream doesn't terminate mid-block. The official Go download page publishes SHA-256 digests for every release — adding a `sha256sum --check` step before `tar` would close this gap and is a standard practice in secure Dockerfiles that fetch remote binaries.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

Conditional install may silently use wrong Go version

The guard if ! command -v go >/dev/null 2>&1 skips installation whenever any go binary is on the PATH — regardless of version. The comment states the intent is to install "the version used by the task's test runner" (1.23.1), but if the base image happens to ship Go at a different version the condition will pass, go mod download will run with that version, and the ENV PATH extension will simply prepend the non-existent /usr/local/go/bin without error. The baked module cache may then be incompatible with whatever go the agent or verifier actually resolves at runtime. Pinning the check to the exact version string (e.g. go version | grep -q go1.23.1) would make this intent explicit and enforceable.

Prompt To Fix With AI

This is a comment left during a code review.
Path: data/tw/task-6902ef3ab97fe23e2ad27209/environment/Dockerfile
Line: 8-16

Comment:
**Conditional install may silently use wrong Go version**

The guard `if ! command -v go >/dev/null 2>&1` skips installation whenever any `go` binary is on the PATH — regardless of version. The comment states the intent is to install "the version used by the task's test runner" (1.23.1), but if the base image happens to ship Go at a different version the condition will pass, `go mod download` will run with that version, and the `ENV PATH` extension will simply prepend the non-existent `/usr/local/go/bin` without error. The baked module cache may then be incompatible with whatever `go` the agent or verifier actually resolves at runtime. Pinning the check to the exact version string (e.g. `go version | grep -q go1.23.1`) would make this intent explicit and enforceable.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

Architecture hard-coded to linux-amd64

The tarball name go1.23.1.linux-amd64.tar.gz will install the wrong binary — or fail at runtime under non-emulated execution — if the Docker build ever runs on an ARM64 host. The 37 other tasks rely on whatever Go the base image ships (which is presumably already arch-appropriate), but this task installs from a fixed URL. Consider using $(dpkg --print-architecture) or $(uname -m) to derive the correct suffix, or document the assumption that build infrastructure is always x86-64.

Prompt To Fix With AI

This is a comment left during a code review.
Path: data/tw/task-6902ef3ab97fe23e2ad27209/environment/Dockerfile
Line: 11

Comment:
**Architecture hard-coded to `linux-amd64`**

The tarball name `go1.23.1.linux-amd64.tar.gz` will install the wrong binary — or fail at runtime under non-emulated execution — if the Docker build ever runs on an ARM64 host. The 37 other tasks rely on whatever Go the base image ships (which is presumably already arch-appropriate), but this task installs from a fixed URL. Consider using `$(dpkg --print-architecture)` or `$(uname -m)` to derive the correct suffix, or document the assumption that build infrastructure is always x86-64.

How can I resolve this? If you propose a fix, please make it concise.