Agent targeting inheritance is still causing me problems. The previous solution has been working for months, but now I’m extending the pattern to another pipeline and no joy.
I run this function
# Launch a K3s server with a waiting buildkite agent, then generate the
# integration test steps for that specific agent.
cue export \
-t build_number=$BUILDKITE_BUILD_NUMBER \
-t pipeline_slug=$BUILDKITE_PIPELINE_SLUG \
.buildkite/generate_integration_tests.cue | buildkite-agent pipeline upload
It uses the
cue tool to generate json (steps) to stdout.
It runs in the context of this step
- label: "Generate integration tests"
- ./scripts/cibuild generate_integration_tests
In our current setup, I must specify
container_image, but because I’ve generated additional steps, the resulting agent targeting includes
container_image, even though I explicitly set an
agents: directive in the generated steps.
It’s the same story, basically. But the
cue dependency forces my hand here, I have to specify
container_image: ubuntu-2204-ci to run my step in an environment where the
cue cli is guaranteed to be there.
It would probably be more convenient if we used
queue to specify the build environment, because that’s always implicitly present anyway, but for now I’m going to work around it by tagging my ephemeral ec2 with
What I’d love to see is a special case for
buildkite-agent pipeline upload at the very least, to not inherit their parent step’s tags, at the very least. Maybe via a flag or something.
In the meantime, I’m adding this advice in my CUE file.
// run `cue injection help` to see how to set data from the command line
buildkite_build_number: string @tag(build_number)
buildkite_pipeline_slug: string @tag(pipeline_slug)
// Generated steps inherit their parent's agent targeting, unfortunately.
// We have to explicitly set these extra values here, and ensure that
// the EC2 we are targeting as them set as tags, as well.