campaigns: handle non-root volume use cases more gracefully#434
Conversation
mrnugget
left a comment
There was a problem hiding this comment.
Approve because I don't see anything that's wrong with this approach.
I'm not too concerned about the []Step being passed to the workspace creators, since I'm pretty sure that more information would be required in the workspace creators as soon as we support the "run steps in subdirectory" functionality. We'll probably want to bundle repo and steps and zip and other stuff into workspaceParams or something.
This can be reverted once we land #434.
This can be reverted once we land #434.
9dc2bcf to
de59a38
Compare
This reverts commit a35c2e7.
f8ad0b5 to
9f8b853
Compare
|
This is ready for review. Note that it currently includes #440; I intend to merge that first, then this. (Sorry for the review noise.) |
|
I have merged #440, so disregard that. The thing that has changed since draft reviews is mostly adding testing, so that's where I'd appreciate some extra review work, in spite of the previous approvals. Thanks! |
mrnugget
left a comment
There was a problem hiding this comment.
Cool! Tested it locally too, with the pin-docker-images and a hello-world campaign, with both bind and volume (using Docker for mac 3.0.1)
eseliger
left a comment
There was a problem hiding this comment.
Still LGTM :) Thanks for adding such a ton of tests!
This can be reverted once we land #434.
This reverts commit a35c2e7. Co-authored-by: Thorsten Ball <mrnugget@gmail.com>
This builds on #433 to handle the case where a user explicitly selects
-workspace volume: we have to inspect the first container when creating the workspace when that happens, so we might as well do that anyway and keep the best workspace detector simple.The major catch here is that workspace creators now have to have knowledge of the campaign spec steps, but I don't really see a clean way around that.
Implementation wise, this splits out our Docker image handling into a new
internal/campaigns/dockerpackage. This creates a fairly noisy looking diff, but it's not wildly different from what we had conceptually; it just unifies some of the details and simplifies the code ininternal/campaigns, particularly inService.Fixes #432.