-
Notifications
You must be signed in to change notification settings - Fork 925
Spawn docker build relative to the Dockerfile #9729
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
🦋 Changeset detectedLatest commit: bcacff9 The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Thank you 🚀 |
create-cloudflare
@cloudflare/kv-asset-handler
miniflare
@cloudflare/pages-shared
@cloudflare/unenv-preset
@cloudflare/vite-plugin
@cloudflare/vitest-pool-workers
@cloudflare/workers-editor-shared
wrangler
commit: |
Realized that we want the dirname of the dockerfile path, not the dockerfile path :/ |
hey, thanks for the contribution! would you be able to add a regression test for this? probably in |
also i'm not sure if misunderstanding the problem, but do we want to spawn docker relative to the dockerfile? the dockerfile and image_build_context is defined in the wrangler config relative to the wrangler config, so it would make sense to spawn docker relative to the wrangler config too, and pass in the paths defined there. there might be a bug with how we resolve paths, but i'm struggling to reproduce. can you give an example of something that fails without this fix and works with? (i guess this comment is also just still asking for the regression test :p) |
Hey Emily, I should have more time to look into this tomorrow, but the general issue is for when you have a setup that looks like: cloudflare/wrangler.jsonc And you need the Dockerfile in the scope of the docker build, so you specify ".." for the image, but the build fails / COPYs fail because docker is run from CWD=./cloudflare According to the docs: image_build_context: "The build context of the application, by default it is the directory of image." |
ah i see if i deploy with that file structure, I was confused because it doesn't seem to happen in dev. I think the actual bug is on this line:
it should be falling back to the directory of the dockerfile rather than the cwd - buildContext is what gets passed into the docker build command, and the build command itself can spawn from wherever. also, does setting sorry for all the back and forth, just making sure we've not messed this up in multiple places! thanks so much for the contribution 🧡 |
1fe108a
to
ed5604a
Compare
ed5604a
to
ae4b2a5
Compare
}, | ||
} as unknown as ChildProcess; | ||
}) | ||
// 2. docker image inspect |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this test need 2, 3, 4, 5 ?
Sounds like what we want to test is the build path ("resolve the docker build context path based on the dockerfile location, if image_build_context is not provided")
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i wanted to test all the config resolution up until the build, but I don't think there's a good way to test just that part of the deploy path?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that ideally we should test that pathToDockerFile
is correctly set by the build command. And then add another test testing that the build command reflects the passed value (explicit path or default to Dockerfile)
With the current, there are ~100 LOC that are not related to what we are trying to test and that might need to be updated when something unrelated to what we want to test changes.
If there is no easy/quick way to fix this, I don't think it should block merging the PR but we should revisit later. It could benefit test speed, coverage and maintainability.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with a few suggestions
@@ -28,7 +28,7 @@ export async function constructBuildCommand( | |||
const dockerfile = readFileSync(options.pathToDockerfile, "utf-8"); | |||
// pipe in the dockerfile | |||
buildCmd.push("-f", "-"); | |||
buildCmd.push(options.buildContext); | |||
buildCmd.push(options.buildContext ?? path.dirname(options.pathToDockerfile)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add some JSDoc to the function to describe this behavior?
@@ -10,7 +10,8 @@ export type BuildArgs = { | |||
/** image tag in the format `name:tag`, where tag is optional */ | |||
tag: string; | |||
pathToDockerfile: string; | |||
buildContext: string; | |||
/** image_build_context or args.PATH. if not provided, defaults to the dockerfile directory */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 for updating the doc
Congratulations @404Wolf, the maintainer of this repository has issued you a holobyte! Here it is: https://holopin.io/holobyte/cmcp29fn9367107i264bxxicw This badge can only be claimed by you, so make sure that your GitHub account is linked to your Holopin account. You can manage those preferences here: https://holopin.io/account. |
Fixes this beta container issue.
Set build context relative to the Dockerfile so that
COPY
s do not break.Also just cleaning up some duplicated helpers tests