31 ms·

I don't see the gotcha, that's how it is supposed to work. It's just their purpose

BonusPlay 2y ago
The gotcha is that "global" args don't propagate automatically to all stages (thin includes 1 stage builds). I want this one arg in multiple stages, so I'll declare it above everything is the chain of thought.
- johanbcn 2y ago
  It's explained on the official documentation: https://docs.docker.com/reference/dockerfile/#scope https://docs.docker.com/reference/dockerfile/#scope
  - hombre_fatal 2y ago
    True, though gotchas exist when user intuition doesn't match with actual behavior regardless of whether they are mentioned in docs.
    - chii 2y ago
      Principle of least surprise. If you need to write in the docs about a surprise that a user otherwise wouldn't have expected, may be it's a sign that the surprise should be fixed up such that it's not surprising behaviour.
      - deleted 2y ago
        [deleted]
- koito17 2y ago
  I interpret each directive in a Dockerfile as creating a new layer of an image. So this ARG-before-FROM gotcha doesn't feel like a gotcha to me, but rather, the consequence of literally interpreting "ARG" and not knowing the side-effects of a directive in a Dockerfile. (Yes, even WORKDIR, ENTRYPOINT, and related instructions create a layer, albeit a 0-byte one)
  - fireflash38 2y ago
    It persists across every other new layer. It just doesn't persist across FROM.
Joker_vD 2y ago
The gotcha is that users only read the smallest possible amount of docs (which is usually zero), at the most "focused" placed (e.g. the docs for exactly one command they suspect is misbehaving, not for all of the commands used in the script, and definitely not the intro into the docs where the concepts are explained), and the doc writers don't bother to duplicate the information in all the relevant places.
- resonious 2y ago
  This is true, and then they will complain about lack of or poor documentation.
  - lucumo 2y ago
    To be fair, if the documentation isn't meeting the users' needs it is poor documentation. One of my more tongue-in-cheek maxims is that too much documentation is worse than too little. With too much documentation the information might be there, but you aren't able to find it. The outcome is the same, but with too much documentation you've just wasted an hour failing. It's slightly tongue-in-cheek because you can push the amount of documentation pretty far, but you have to think about how to organise it and how users will get the required information when and if they need it.
    - codetrotter 2y ago
      LLMs augumented with RAG has great potential for docs as well. Have a problem, ask the LL and it will reference the docs. So you don’t have to read through 40 pages just to find an answer. Some products already make use of it for their docs. More will in the future. The advantage then is that you can have up to date docs that the LLM can pull from and be able to hopefully accurately pinpoint relevant docs and summarize an answer for the user. I also think some startups will come that focus on providing this kind of service. Probably several such startups exist already even. Similar to how there are some companies from before LLMs existed that focused purely on better access to docs of open source products.
    - dspillett 2y ago
mikehollinger 2y ago
> I don't see the gotcha, that's how it is supposed to work. It's just their purpose The issue here is that docker evolved rather rapidly and in a “let a thousand flowers bloom” sort of manner. And because of that you have these subtle but confusing differences between behaviors that aren’t really all that consistent. A good example of this is how the shell is handled from layer to layer(sorta this) or even how CMD and ENTRYPOINT behave (or don’t). If the spec has allowances for behaviors like this generating warnings would be the best possible outcome (eg referencing a variable that theoretically isn’t set). Maybe certain runtime / runc / build envs complain but the author didn’t see the complaint.

The gotcha is that "global" args don't propagate automatically to all stages (thin includes 1 stage builds). I want this one arg in multiple stages, so I'll declare it above everything is the chain of thought.

johanbcn 2y ago
It's explained on the official documentation: https://docs.docker.com/reference/dockerfile/#scope https://docs.docker.com/reference/dockerfile/#scope
- hombre_fatal 2y ago
  True, though gotchas exist when user intuition doesn't match with actual behavior regardless of whether they are mentioned in docs.
  - chii 2y ago
    Principle of least surprise. If you need to write in the docs about a surprise that a user otherwise wouldn't have expected, may be it's a sign that the surprise should be fixed up such that it's not surprising behaviour.
    - deleted 2y ago
      [deleted]
koito17 2y ago
I interpret each directive in a Dockerfile as creating a new layer of an image. So this ARG-before-FROM gotcha doesn't feel like a gotcha to me, but rather, the consequence of literally interpreting "ARG" and not knowing the side-effects of a directive in a Dockerfile. (Yes, even WORKDIR, ENTRYPOINT, and related instructions create a layer, albeit a 0-byte one)
- fireflash38 2y ago
  It persists across every other new layer. It just doesn't persist across FROM.

Joker_vD 2y ago

The gotcha is that users only read the smallest possible amount of docs (which is usually zero), at the most "focused" placed (e.g. the docs for exactly one command they suspect is misbehaving, not for all of the commands used in the script, and definitely not the intro into the docs where the concepts are explained), and the doc writers don't bother to duplicate the information in all the relevant places.

resonious 2y ago
This is true, and then they will complain about lack of or poor documentation.
- lucumo 2y ago
  To be fair, if the documentation isn't meeting the users' needs it is poor documentation. One of my more tongue-in-cheek maxims is that too much documentation is worse than too little. With too much documentation the information might be there, but you aren't able to find it. The outcome is the same, but with too much documentation you've just wasted an hour failing. It's slightly tongue-in-cheek because you can push the amount of documentation pretty far, but you have to think about how to organise it and how users will get the required information when and if they need it.
  - codetrotter 2y ago
    LLMs augumented with RAG has great potential for docs as well. Have a problem, ask the LL and it will reference the docs. So you don’t have to read through 40 pages just to find an answer. Some products already make use of it for their docs. More will in the future. The advantage then is that you can have up to date docs that the LLM can pull from and be able to hopefully accurately pinpoint relevant docs and summarize an answer for the user. I also think some startups will come that focus on providing this kind of service. Probably several such startups exist already even. Similar to how there are some companies from before LLMs existed that focused purely on better access to docs of open source products.
  - dspillett 2y ago

mikehollinger 2y ago

> I don't see the gotcha, that's how it is supposed to work. It's just their purpose The issue here is that docker evolved rather rapidly and in a “let a thousand flowers bloom” sort of manner. And because of that you have these subtle but confusing differences between behaviors that aren’t really all that consistent. A good example of this is how the shell is handled from layer to layer(sorta this) or even how CMD and ENTRYPOINT behave (or don’t). If the spec has allowances for behaviors like this generating warnings would be the best possible outcome (eg referencing a variable that theoretically isn’t set). Maybe certain runtime / runc / build envs complain but the author didn’t see the complaint.