ci(render-quarto): pass GITHUB_TOKEN as BuildKit secret to avoid Docker API rate limit

[anshul23102]

Summary

The render-notebook CI job was failing intermittently with:

Error: HTTP error 403.
  API rate limit exceeded for <runner IP>.

This happened inside the Docker build step at modules/data.atmosphere, where confirm_deps.R calls remotes::install_deps() when a package dependency is not already cached in pecan/depends:latest. Those calls hit the unauthenticated GitHub API (60 req/hr limit), which is exhausted during concurrent CI runs.

Fix: Enable Docker BuildKit and pass GITHUB_TOKEN from the GitHub Actions environment as a BuildKit secret. The secret is mounted read-only inside the single RUN layer via --mount=type=secret, exported as GITHUB_PAT (the variable remotes consults automatically), and is never written into any image layer -- it does not appear in docker history or image metadata.

Authenticated requests receive 5,000 req/hr, well above what the make dependency checks need.

Changes

• .github/workflows/render-quarto.yml: enable DOCKER_BUILDKIT=1, pass GITHUB_TOKEN as a BuildKit secret to docker build.
• docker/base/Dockerfile: use --mount=type=secret,id=GITHUB_PAT in the RUN layer so the token is available as $GITHUB_PAT during make.

Test plan

• render-notebook CI passes on this PR
• Verify Docker image still builds correctly (secret is consumed, not stored)

[infotroph]

@anshul23102 Thanks for working on this and for your patience with the wait for review.

I'm curious why you're passing the token only to the base build and not to other builds, especiallydepends since that's where I believe the majority of the API calls in a Docker build session originate.

For context, when we've used this approach in the past (see #3083) we passed the secret to all three of the api, depends, and base builds. They were removed in our last major overhaul of the Docker build (#3354) because it didn't seem needed at the time; now that it seems needed again I'm on board with bringing it back.

Ping @robkooper: Any other factors we should consider before re-adding secrets?

[anshul23102]

@infotroph Good question, and the answer turns out to hinge on a structural difference between this workflow and the main Docker GHA.

render-quarto.yml only builds the base image, never depends.

The depends image is not rebuilt in this workflow at all. The docker build step in render-quarto.yml starts FROM pecan/depends:latest, which is a pre-built image pulled from Docker Hub. The docker/depends/Dockerfile and pecan.depends.R (which call remotes::install_github()) are never invoked here. There is therefore no depends build step to pass a secret to.

The GitHub API calls that caused the rate-limit failure came from scripts/confirm_deps.R, which runs inside the base image build when make processes modules/data.atmosphere. If any declared dependency is missing or outdated, confirm_deps falls through to remotes::install_deps(), which queries GitHub for non-CRAN remotes. Passing the token to the base build step is sufficient to fix the failure in this workflow.

On the broader picture: the main Docker GHA already passes GITHUB_PAT to all image builds.

Looking at .github/workflows/docker-build-image.yml line 150, the reusable workflow passes GITHUB_PAT to every image (depends, base, models, and extras) as a --build-arg. This covers the depends build that @infotroph mentioned. The difference is that --build-arg bakes the value into the image layer and it is visible in docker history, whereas --secret in this PR never appears in any layer or metadata. If there is interest in hardening the main workflow to use secrets instead of build args for the token, that would be a worthwhile follow-up, but it touches the production image pipeline and is outside the scope of the render-quarto fix here.

In short: this PR passes the token to the only image that is actually built in render-quarto.yml. Happy to expand it if I have misread the workflow structure.