docker.container: Support container args #1273
Draft
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
This change refactors the way the `docker.container` operation manages containers, in preparation for work to make recreation more intelligent. This change is (mostly) a pure refactor; future changes will diff the current container against the operation parameters to determine if a container needs to be recreated. This will fix an issue where changing any of the operation arguments does not result in actual container changes upon execution. In this refactor, container parameters are moved to a dedicated class, which centralizes the `docker container` command-line argument generation logic and the future diffing logic. The diff function is roughed in, though it currently reports "no diff" (to match the operation's current behavior). Since conditional recreation complicates the operation's logic on which commands to execute, the decisions are boosted into boolean variables to increase readability. As a side benefit, supporting additional docker container parameters should be more straightforward due to the centralization in said dedicated class (I'm planning on adding support for container args, uid, and other Docker params currently not supported). The only behavioral change is that creating and starting a container is no longer done in one exec (joined by `;`) but rather two separate docker commands. This sidesteps questions about whether `;` is the correct joiner (as opposed to `&&`) and reduces the amount of `kwargs` fishing in the implementation. Tested: * `scripts/dev-test.sh` and `scripts/dev-test-e2e.sh` both pass, save for warnings also present prior to this change
This change adds an `args` parameter to the `docker.container` operation that passes said supplied args to the container at creation time. This allows the operation to support container images that have an entrypoint expecting to receive additional arguments, without needing to build+push a custom image that embeds said arguments.
|
Set as draft until dependent change #1272 lands |
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.
This change adds an
argsparameter to thedocker.containeroperationthat passes said supplied args to the container at creation time. This
allows the operation to support container images that have an entrypoint
expecting to receive additional arguments, without needing to build+push
a custom image that embeds said arguments.