Support proxy environment variables in jq/sentry/cron Docker builds

[oddballfr]

Problem

Deployers building self-hosted behind a corporate HTTP/HTTPS proxy have no way to have that proxy applied during the docker build/docker compose build steps for the jq, sentry, and cron images.

install/dc-detect-version.sh already computes and passes --build-arg HTTP_PROXY=... --build-arg HTTPS_PROXY=... --build-arg http_proxy=... --build-arg https_proxy=... (sourced from .env.custom, the documented proxy override file) to both dcb (docker compose build) and dbuild (docker build, used for jq). However, none of the three Dockerfiles declare these as ARGs, so the values are silently discarded and never reach apt-get/pip inside the build.

In practice this causes builds to fail behind a proxy — for example pip install in sentry/Dockerfile times out trying to reach github.com directly.

Fix

Declare and consume the standard proxy build args (HTTP_PROXY, HTTPS_PROXY, http_proxy, https_proxy) in all three Dockerfiles, and forward them from docker-compose.yml:

• jq/Dockerfile, sentry/Dockerfile, cron/Dockerfile: add ARG/ENV declarations for HTTP_PROXY/HTTPS_PROXY/http_proxy/https_proxy right after FROM, so they're available to every subsequent RUN (apt, pip, etc.). jq/Dockerfile and cron/Dockerfile also configure apt's proxy explicitly (Acquire::http::proxy/Acquire::https::proxy) when set, matching the pattern already used elsewhere.
• docker-compose.yml: add HTTP_PROXY/HTTPS_PROXY/http_proxy/https_proxy to x-sentry-defaults.build.args and to the cron/sentry-cleanup service's build.args, since Compose does not forward arbitrary CLI
• --build-arg names to a service unless they're also declared in that service's own build.args.

No proxy URL or domain is hardcoded anywhere — everything is driven purely by whatever the deployer sets in .env.custom (or their shell environment), exactly as documented in the self-hosted proxy configuration docs. Deployments with no proxy configured are unaffected (ARGs default to empty, if [ -n "..." ] guards skip the apt proxy config).

Testing

Validated on an internal self-hosted deployment behind a corporate HTTP proxy:

• Confirmed via a temporary debug RUN env | grep -i proxy that HTTP_PROXY/HTTPS_PROXY/http_proxy/https_proxy are correctly populated inside the sentry image build.
• Confirmed pip install https://github.com/getsentry/sentry-nodestore-s3/archive/main.zip succeeds through the proxy, where it previously timed out.
• Confirmed the jq image build (plain docker build, not Compose) picks up the same args correctly.

Legal Boilerplate

Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 9e6db93. Configure here.}

[sentry]

Bug: The sentry, cron, and jq Dockerfiles are missing ARG NO_PROXY and ARG no_proxy declarations, causing Docker to ignore these build arguments during installation.
_{Severity: MEDIUM}

Suggested Fix

Add ARG NO_PROXY and ARG no_proxy to the sentry/Dockerfile, cron/Dockerfile, and jq/Dockerfile. This will ensure Docker correctly processes these build arguments and configures the environment to respect proxy exclusion lists.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: sentry/Dockerfile#L4-L7

Potential issue: The Dockerfiles for `sentry`, `cron`, and `jq` declare `ARG` for proxy
variables like `HTTP_PROXY` but fail to declare `ARG NO_PROXY` or `ARG no_proxy`.
Although the installation script passes these as build arguments, Docker silently
discards them. This causes tools like `pip` and `apt-get` to ignore proxy exclusion
lists, which can break builds in corporate environments that use internal package
mirrors for dependencies.

Also affects:

• cron/Dockerfile
• jq/Dockerfile

[oddballfr]

Not adding explicit NO_PROXY handling — Docker already passes it through as an env var to every RUN step once declared as ARG, and the build works fine without it, so there's no need to force it.

[aminvakil]

It's ok to use AI to open merge requests, but write PR in your own words, I cannot review this in this current state.

[aminvakil]

And this is completely wrong, it's completely unnecessary, please do not open PRs for the sake of opening PRs.

[oddballfr]

Sorry if the description didn't meet expectations — I used AI to help format the write-up, but the fix itself comes from a real need on my end, not something invented for the sake of it.

My setup isn't a fully open Docker environment: my servers run in a DMZ behind a filtering Squid proxy. I already set my proxy config in .env.custom, and it works well everywhere — except for these 3 image builds, which is a bit frustrating since I don't run into this anywhere else.

That's also why I opened #4441 alongside this one — it's the same kind of constraint many companies deal with. Since v25, I've been maintaining a small bash script on my side just to patch your Dockerfiles and force the proxy during install so the build goes through.

I understand if the PR needs rework, and I'm happy to adjust it. I just wanted to share this fix in case it's useful to others in a similar setup — and I hope the form isn't the only reason behind the rejection, since without it the build genuinely doesn't work for me in a security-constrained environment.