[marcleblanc2]

Follow-up to sourcegraph/deploy-sourcegraph-docker#1461, same cleanup for the Helm chart.

Four templates still set PRECISE_CODE_INTEL_UPLOAD_BACKEND=blobstore and PRECISE_CODE_INTEL_UPLOAD_AWS_ENDPOINT=http://blobstore:9000 under {{ if .Values.blobstore.enabled }}: frontend, worker, precise-code-intel-worker, and syntactic-code-intel-worker. A customer reading the templates could reasonably think both PRECISE_CODE_INTEL_UPLOAD_* and SOURCEGRAPH_UPLOAD_* need changing to move to S3 or GCS. This removes the legacy lines so SOURCEGRAPH_UPLOAD_* in *.env is the only object storage configuration in the chart, matching the external-object-storage examples.

The removed values did nothing:

• They are the built-in defaults: PRECISE_CODE_INTEL_UPLOAD_BACKEND defaults to blobstore (lsifuploadstore/config.go), and the endpoint defaults to http://blobstore:9000 outside the single-container deployment (deploy/endpoints.go).
• When the legacy backend is blobstore, resolveLegacyCompatStorage uses the shared SOURCEGRAPH_UPLOAD_* config and keeps only the legacy bucket name, so the legacy endpoint was never read.

Impact on existing deployments

• Default (bundled blobstore): no change. The rendered env loses two variables whose values equal the compiled-in defaults, so pods restart on upgrade (env changed) but behave identically: bundled blobstore, lsif-uploads bucket.
• blobstore.enabled: false with SOURCEGRAPH_UPLOAD_* in *.env (the documented path): no change at all. The removed block never rendered for these deployments, so the manifests are byte-identical.
• blobstore.enabled: true with SOURCEGRAPH_UPLOAD_BACKEND=S3|GCS in *.env: no change. Code-intel uploads already went to the shared bucket under the lsif-uploads/ prefix via the compat shim, and still do.
• blobstore.enabled: true with PRECISE_CODE_INTEL_UPLOAD_BACKEND=S3|GCS in *.env: behaviour fix, one upgrade later. The chart's hardcoded blobstore rendered after *.env, and Kubernetes takes the last duplicate env name, so these overrides were silently ignored and uploads went to the bundled blobstore. On the upgrade to this chart, Helm's three-way merge deletes every env entry with those names, the *.env override included, so the live Deployments carry neither value and runtime behaviour is unchanged (the deleted values equal the built-in defaults). On the next helm upgrade, even one with no changes, the override is rendered once, takes effect, and uploads switch to the dedicated bucket the customer configured. Before that second upgrade, make sure the bucket exists and is reachable, or move the settings to SOURCEGRAPH_UPLOAD_*, or remove them. Running a second helm upgrade straight away makes the switch happen at a known time. Existing uploads in the bundled blobstore are not migrated. Verified on a kind cluster by @bobheadxi's agent, see the comment below.

Impact on new deployments

None beyond less to read. The external-object-storage examples already disable blobstore and set only SOURCEGRAPH_UPLOAD_*.

Test plan

• helm lint and helm unittest ./charts/sourcegraph pass (218 tests, 12 snapshots).
• helm template of origin/main vs this branch with default values: the only difference is the two variables removed from the three services that render by default (syntactic-code-intel-worker is disabled by default).
• helm template --set frontend.env.PRECISE_CODE_INTEL_UPLOAD_BACKEND.value=S3 on origin/main renders S3 followed by a second blobstore entry; on this branch it renders S3 once.
• CI.

[github-actions]

Open the Diff Tour for this PR in Sourcegraph

[bobheadxi]

🤖 I'm an AI agent (Amp), posting on behalf of @bobheadxi. I tested this PR on a real cluster. Full details are in the Amp thread.

Warning

TL;DR: the description needs a fix before merging. The template change is correct, and default and documented setups are unaffected. But for deployments with blobstore.enabled: true that set PRECISE_CODE_INTEL_UPLOAD_* in *.env, the description and CHANGELOG get the timing wrong. Their override does not take effect on this upgrade. This upgrade deletes it from the live Deployments, and it comes back on the next helm upgrade, which is when uploads switch buckets. Details and a suggested wording fix are below.

The template change looks correct. Comparing helm template output for main and this branch:

• With default values, the only difference is the two variables removed from frontend, worker and precise-code-intel-worker.
• With blobstore.enabled=false, the output is byte-identical.
• With syntacticCodeIntel.enabled=true, the syntactic worker loses the same two variables.

Upgrading a default install from main to this branch on kind (Kubernetes v1.37) with Helm 3.22.1 and Helm 4.3.1 removes just those two variables. The images are the same 8.1.2687 ones I tested end to end for sourcegraph/deploy-sourcegraph-docker#1461, where uploads land in the same bucket and key before and after the removal.

One claim in the description and CHANGELOG is inaccurate. It's about deployments with blobstore.enabled: true that also set PRECISE_CODE_INTEL_UPLOAD_* in *.env. The description says those overrides take effect with this upgrade. On a real cluster they take effect one upgrade later. The test installed main with Helm 3 and frontend/worker/preciseCodeIntel.env setting PRECISE_CODE_INTEL_UPLOAD_BACKEND=S3, a bucket and an AWS endpoint:

Step	Live Deployment env (all three services)
Install main	BACKEND and AWS_ENDPOINT each appear twice. The chart's blobstore entries come last and win, so the effective backend is blobstore.
helm upgrade to this branch	Only BUCKET remains. Both duplicate entries of each name are deleted, the customer's S3 included.
Another helm upgrade, nothing changed	The customer's S3 values come back, and uploads switch to their bucket at this point.

Upgrading the same Helm 3 release with Helm 4 does the same thing. The API server warns about this when the duplicates are created: hides previous definition of "PRECISE_CODE_INTEL_UPLOAD_BACKEND", which may be dropped when using apply. Helm's client-side three-way merge then deletes every entry with that name. A fresh Helm 4 install of main with that override can't get into this state at all: it fails with duplicate entries for key [name="PRECISE_CODE_INTEL_UPLOAD_BACKEND"].

The first upgrade doesn't change runtime behaviour, because the deleted values equal the built-in defaults. But the "check that bucket exists before upgrading" warning comes one upgrade too early. The switch happens on the next helm upgrade after this one, even one with no changes.

Suggested fix (text only, no template change): say in the description and CHANGELOG that in this setup, the PRECISE_CODE_INTEL_UPLOAD_* override starts applying on the next helm upgrade after this one. Before that, customers should make sure the bucket exists, or move the settings to SOURCEGRAPH_UPLOAD_* or remove them. Running a second helm upgrade straight away makes the switch happen at a known time.