-
Notifications
You must be signed in to change notification settings - Fork 833
Implement docker.#Dockerfile #1525
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
|
✔️ Deploy Preview for devel-docs-dagger-io ready! 🔨 Explore the source changes: c6da3ee 🔍 Inspect the deploy log: https://app.netlify.com/sites/devel-docs-dagger-io/deploys/62346f5afa5d3a00088530bf 😎 Browse the preview: https://deploy-preview-1525--devel-docs-dagger-io.netlify.app |
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.
this inconsistency will go away with #1452
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.
Drift: This is called input in docker.#Dockerfile and source in engine.#Dockerfile
@shykes should we converge the two?
Also, I don't think this should be optional?
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.
So how should we handle the case where someone start a docker.#Build with a docker.#Dockerfile?
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.
Good point, I don't know.
If we want to support that, IMHO it should be in engine.#Dockerfile rather than here. This should be a 1:1 wrapper as much as possible, instead of having a different behavior.
Deferring to @shykes for DX design
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.
The correct field name is source.
- You can't pass an input image to
engine.#Dockerfile, because Dockerfiles specify their own base images withFROM - In that way,
engine.#Dockerfileis similar toengine.#GitPull,engine.#DockerPull,engine.#HTTPFetch: when used in a pipeline, it will always be the first step. - For the same reason,
docker.#Dockerfiledoesn't have an input field either, and when used in adocker.#Buildpipeline, should always be the first step. docker.#Buildsupports this by makinginputoptional in build steps: onlyoutputis mandtory.
Hope this helps.
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.
Not sure this is needed if input is not optional
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.
True, but it should actually (see my response above)
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.
The correct field name is source.
- You can't pass an input image to
engine.#Dockerfile, because Dockerfiles specify their own base images withFROM - In that way,
engine.#Dockerfileis similar toengine.#GitPull,engine.#DockerPull,engine.#HTTPFetch: when used in a pipeline, it will always be the first step. - For the same reason,
docker.#Dockerfiledoesn't have an input field either, and when used in adocker.#Buildpipeline, should always be the first step. docker.#Buildsupports this by makinginputoptional in build steps: onlyoutputis mandtory.
Hope this helps.
|
Sorry for the delay in review. It's been a busy couple weeks! |
|
Picking this up. Do we still want this merged for the release? |
|
This PR is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 7 days. |
|
This PR was closed because it has been stalled for 7 days with no activity. |
|
@aluzzardi I will assume that this something that we want to merge in for @TomChv is going to clean it up and I am going to merge it if everything checks out. I am doing a code review now, before the last changes land, so that it can get merged in the next hour. Thank you @helderco for mentioning this PR in this morning's Europe sync 🙌🏻 |
Signed-off-by: Vasek - Tom C <[email protected]>
Signed-off-by: Vasek - Tom C <[email protected]>
- Remove input field - Fix auth consistency - Cleanup test Signed-off-by: Vasek - Tom C <[email protected]>
Signed-off-by: Vasek - Tom C <[email protected]>
gerhard
left a comment
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.
Everything checks for me, merging.
|
@TomChv if this fixes an issue, please mark it so. Same if there is a task in an issue that this ✅ |
|
Before we merge this, how do you feel about moving this to a subpackage |
|
While these changes are already merged, I value your improvement principle @shykes. I can see how splitting all definitions into their own individual files would help with discoverability. I am unsure whether editor tags - in the vim tags sense - exist in the CUE ecosystem, but that is how I usually prefer to jump to definitions in a programming language. This is one of my favourite features of vim-go for example. The point being that with that approach, it really doesn't matter whether all definitions are in one file, or spread across multiple files. I am on the fence with this one. Regardless what we decide to do, being consistent is most important, and everyone knowing which approach to use going forward would help greatly. What are your thoughts on this @aluzzardi? |
|
As I said before. Please do not merge any changes to universe without my review... Please. |
Changes
Related to #1407.
Implement
docker.#Dockerfiledefinition which is basically a mirror onengine.#DockerfileTests