Allow patching some container commands/args #461
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
DrJosh9000
force-pushed
the
allow-some-command-patching
branch
3 times, most recently
from
e8c4537 to
c24a4bf
Compare
DrJosh9000
force-pushed
the
allow-some-command-patching
branch
from
c24a4bf to
9d4505e
Compare
wolfeidau
approved these changes
Dec 19, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It came to me last night in a dream... wait, why am I dreaming about work? 🫤
What
Allow patching some container commands and args with PodSpecPatch: sidecars and new containers added by patch are allowed to make any command/args modification, and command container patches are interposed back into
BUILDKITE_COMMANDform as we do for non-patch containers.Why
The command modification check was added to prevent breaking the pod. I wrote an explanation in #449 - if
buildkite-agent startisn't run in the agent container, orbuildkite-agent bootstrapisn't run in the checkout or command containers, the pod will break in various ways.However, it was always too strict:
buildkite-agentadded to it, so they should be modifiableWhat about command containers? I think if a user tried to override the command/args of a command container, they probably expect the patch to be interpreted the same way as we do currently for command containers specified with
podSpec: substitutebuildkite-agent bootstrapfor the command and interpose the supplied command intoBUILDKITE_COMMAND.Original command containers can be identified by having had this transform already applied, so we just need to match them against the patch by the same process that strategic merge patch uses: container name.
Patching the checkout container is more complicated - it's a container we add rather than one the user supplies anywhere else, with scripts for adjusting user and group IDs, etc. What do we do with a user supplied command? (schlep it into a checkout hook? that could work... 🤔 but what if the user supplied a checkout hook already?)