Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@TomChv
Copy link
Member

@TomChv TomChv commented Jan 28, 2022

Changes

Related to #1407.

Implement docker.#Dockerfile definition which is basically a mirror on engine.#Dockerfile

⚠️ This PR will have conflict with #1524, a rebase will be necessary since I wanted to split those two improvement.

Tests

  • Build an image with an aligned dockerfile
  • Build an image with an input

@TomChv TomChv requested a review from aluzzardi January 28, 2022 13:57
@TomChv TomChv self-assigned this Jan 28, 2022
@netlify
Copy link

netlify bot commented Jan 28, 2022

✔️ 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

Copy link
Contributor

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

Copy link
Contributor

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?

Copy link
Member Author

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?

Copy link
Contributor

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

Copy link
Contributor

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 with FROM
  • In that way, engine.#Dockerfile is similar to engine.#GitPull, engine.#DockerPull, engine.#HTTPFetch: when used in a pipeline, it will always be the first step.
  • For the same reason, docker.#Dockerfile doesn't have an input field either, and when used in a docker.#Build pipeline, should always be the first step.
  • docker.#Buildsupports this by making input optional in build steps: only output is mandtory.
    Hope this helps.

Copy link
Contributor

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

Copy link
Member Author

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)

Copy link
Contributor

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 with FROM
  • In that way, engine.#Dockerfile is similar to engine.#GitPull, engine.#DockerPull, engine.#HTTPFetch: when used in a pipeline, it will always be the first step.
  • For the same reason, docker.#Dockerfile doesn't have an input field either, and when used in a docker.#Build pipeline, should always be the first step.
  • docker.#Buildsupports this by making input optional in build steps: only output is mandtory.
    Hope this helps.

@shykes
Copy link
Contributor

shykes commented Feb 11, 2022

Sorry for the delay in review. It's been a busy couple weeks!

@TomChv TomChv requested review from aluzzardi and shykes and removed request for shykes February 17, 2022 16:49
@shykes
Copy link
Contributor

shykes commented Feb 23, 2022

Picking this up. Do we still want this merged for the release?

@github-actions
Copy link
Contributor

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.

@github-actions
Copy link
Contributor

This PR was closed because it has been stalled for 7 days with no activity.

@github-actions github-actions bot closed this Mar 18, 2022
@gerhard gerhard reopened this Mar 18, 2022
@gerhard
Copy link
Contributor

gerhard commented Mar 18, 2022

@aluzzardi I will assume that this something that we want to merge in for v0.2.2

@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 🙌🏻

TomChv added 3 commits March 18, 2022 11:58
Signed-off-by: Vasek - Tom C <[email protected]>
- Remove input field
- Fix auth consistency
- Cleanup test

Signed-off-by: Vasek - Tom C <[email protected]>
Copy link
Contributor

@gerhard gerhard left a 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.

@gerhard gerhard merged commit 7492789 into dagger:main Mar 18, 2022
@gerhard gerhard deleted the feat/docker-dockerfile branch March 18, 2022 13:41
@gerhard
Copy link
Contributor

gerhard commented Mar 18, 2022

@TomChv if this fixes an issue, please mark it so. Same if there is a task in an issue that this ✅

@shykes
Copy link
Contributor

shykes commented Mar 18, 2022

Before we merge this, how do you feel about moving this to a subpackage universe.dagger.io/docker/dockerfile with for example dockerfile.#Run?

@gerhard
Copy link
Contributor

gerhard commented Mar 19, 2022

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?

@shykes
Copy link
Contributor

shykes commented Mar 19, 2022

As I said before. Please do not merge any changes to universe without my review... Please.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants