Skip to content

Experiment for propagating agent config env vars#3471

Merged
DrJosh9000 merged 1 commit into
mainfrom
pb-613-propagate-env-vars
Sep 15, 2025
Merged

Experiment for propagating agent config env vars#3471
DrJosh9000 merged 1 commit into
mainfrom
pb-613-propagate-env-vars

Conversation

@DrJosh9000

Copy link
Copy Markdown
Contributor

Description

Add an experiment that enables various agent config vars to be named in the env file.

Context

Closes #3430

Changes

  • Add a new experiment, propagate-agent-config-vars
  • When the experiment is enabled, write an extra preamble to the env file, consisting of various env var names that could be usefully propagated.

Testing

  • Tests have run locally (with go test ./...). Buildkite employees may check this if the pipeline has run automatically.
  • Code is formatted (with go fmt ./...)

Disclosures / Credits

I did not use AI tools at all. I copied the list of env vars from #3430.

@zhming0 zhming0 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code change looks safe so LGTM, but @DrJosh9000 do you mind giving me some context on what use cases are this env file designed for?

I did see #3430 but I don't quite know how env file is used.

@Mykematt Mykematt left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @DrJosh9000 for this. But from my test, even with experiment enabled, new vars does not work when propagate-environment: true is enabled, and this is precisely what we set out to fix.

Consequently, I added the below to agent/job_runner.go:

// Agent configuration variables - set unconditionally for backward compatibility
// Git configuration variables
if r.conf.AgentConfiguration.GitCheckoutFlags != "" {
    env["BUILDKITE_GIT_CHECKOUT_FLAGS"] = r.conf.AgentConfiguration.GitCheckoutFlags
}
if r.conf.AgentConfiguration.GitCleanFlags != "" {
    env["BUILDKITE_GIT_CLEAN_FLAGS"] = r.conf.AgentConfiguration.GitCleanFlags
}
// ... (continue for all 32 agent config variables)

// Tracing variables
if r.conf.AgentConfiguration.TraceContextEncoding != "" {
    env["BUILDKITE_TRACE_CONTEXT_ENCODING"] = r.conf.AgentConfiguration.TraceContextEncoding
}
if r.conf.AgentConfiguration.TracingBackend != "" {
    env["BUILDKITE_TRACING_BACKEND"] = r.conf.AgentConfiguration.TracingBackend
    env["BUILDKITE_TRACING_SERVICE_NAME"] = r.conf.AgentConfiguration.TracingServiceName
    // ... (continue for tracing variables)
}

// Pipeline signing variables
if r.conf.AgentConfiguration.SigningAWSKMSKey != "" {
    env["BUILDKITE_AGENT_AWS_KMS_KEY"] = r.conf.AgentConfiguration.SigningAWSKMSKey
}
// ... (continue for signing variables)

This ensured that in addition to writing variable names to env file they also exist in agent environment. The latter allowed Docker plugins with propagate-environment: true to read from agent environment, not just env file. Without this, variables were missing even when experiment is enabled.

Building a custom agent with this, tests reveal that propagate-environment: true fetched new vars when experiment is enabled.

@DrJosh9000

DrJosh9000 commented Sep 15, 2025

Copy link
Copy Markdown
Contributor Author

Thanks @Mykematt, but can you explain why those env vars are not in the environment readable by the plugin when similar lines of code already exist in agent/job_runner.go to add the environment variables?

  • BUILDKITE_GIT_CHECKOUT_FLAGS:
    env["BUILDKITE_GIT_CHECKOUT_FLAGS"] = r.conf.AgentConfiguration.GitCheckoutFlags
  • BUILDKITE_GIT_CLEAN_FLAGS:
    env["BUILDKITE_GIT_CLEAN_FLAGS"] = r.conf.AgentConfiguration.GitCleanFlags
  • BUILDKITE_TRACE_CONTEXT_ENCODING:
    env["BUILDKITE_TRACE_CONTEXT_ENCODING"] = r.conf.AgentConfiguration.TraceContextEncoding
  • BUILDKITE_TRACING_BACKEND and BUILDKITE_TRACING_SERVICE_NAME:

    agent/agent/job_runner.go

    Lines 602 to 603 in 7d391fe

    env["BUILDKITE_TRACING_BACKEND"] = r.conf.AgentConfiguration.TracingBackend
    env["BUILDKITE_TRACING_SERVICE_NAME"] = r.conf.AgentConfiguration.TracingServiceName
  • BUILDKITE_AGENT_AWS_KMS_KEY:
    env["BUILDKITE_AGENT_AWS_KMS_KEY"] = r.conf.AgentConfiguration.SigningAWSKMSKey

Can you also explain why the two tests you linked used different versions of the docker-compose plugin? (v4.16.0 vs v5.3.0)?

@DrJosh9000

Copy link
Copy Markdown
Contributor Author

@Mykematt I've done some further testing, which shows the env vars are indeed propagating.

Without the experiment: https://buildkite.com/stargoose/propagate-agent-config-vars/builds/31/steps/canvas?sid=01994bb7-9067-4569-aa85-aebb8845fc0b

With the experiment: https://buildkite.com/stargoose/propagate-agent-config-vars/builds/32/steps/canvas?sid=01994bb8-120f-459b-89c6-149082061c65

Note without the experiment the absence of BUILDKITE_GIT_CHECKOUT_FLAGS, BUILDKITE_GIT_CLEAN_FLAGS, BUILDKITE_TRACE_CONTEXT_ENCODING, and so on. Note with the experiment the presence of the same env vars. BUILDKITE_TRACING_BACKEND, BUILDKITE_TRACING_SERVICE_NAME, and BUILDKITE_AGENT_AWS_KMS_KEY are present in neither as I have not configured those agent options.

@DrJosh9000

Copy link
Copy Markdown
Contributor Author

@zhming0:

do you mind giving me some context on what use cases are this env file designed for?

The env file is used by pre-bootstrap hooks to allow custom job validation before running anything else. The env vars are passed via a file specifically to avoid shell injection. See e.g. https://buildkite.com/docs/agent/v3/securing#restrict-access-by-the-buildkite-agent-controller-strict-checks-using-a-pre-bootstrap-hook. Because the format of the file has some quirks, we also write a JSON version, but there will be a few uses of the original env file that I am wary of breaking, given how long it has been in the docs. Hence the need for an experiment (or a different file).

The env file is also used by the docker and docker-compose plugins to figure out what --env flags to pass to Docker, so that the corresponding env vars propagate into the container. The goal here is to propagate more of them this way.

@Mykematt

Copy link
Copy Markdown
Contributor

@DrJosh9000 thanks once again. Looking through your tests, I may have overthought somethings while testing. Your workaround solves what I set out to achieve.

As for the different docker-compose plugin versions, it was an oversight. Ran several tests and possibly confused things there a bit.

Thanks once again for taking a crack at this. I will drop a note in the associated linear allowing us to close it.

@DrJosh9000 DrJosh9000 merged commit f853564 into main Sep 15, 2025
1 check passed
@DrJosh9000 DrJosh9000 deleted the pb-613-propagate-env-vars branch September 15, 2025 23:30
@DrJosh9000

Copy link
Copy Markdown
Contributor Author

@Mykematt And thank you for persisting, agent stuff can be complicated!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants