introduce no_cache and pull to force a full rebuild#232
introduce no_cache and pull to force a full rebuild#232ndeloof merged 5 commits intocompose-spec:masterfrom
no_cache and pull to force a full rebuild#232Conversation
90365d8 to
91eb78b
Compare
Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>
EricHripko
left a comment
There was a problem hiding this comment.
If we are introducing these primarily for CLI flags and don't expect these to be set by the user, should these be documented at all? Taking it further, should these be part of the schema at all? 🤔
|
@EricHripko this is already the case for a bunch of parameter that I don't think user should hardcode in yaml, but some do, because we can't guess all usages... Having this part of the compose spec model makes it more transparent. Typically, using variable interpolation one can declare: services:
foo:
build:
pull: ${DO_NOT_PULL:-false}.. so that by default a fresh pull will always take place (some user/company have a base image moving fast) but still can be disabled by env variable. |
|
Thank you for elaborating 👍 |
EricHripko
left a comment
There was a problem hiding this comment.
Looks great, thank you for looking into this ✅ Left a suggestion inline, feel free to land once it's addressed.
Co-authored-by: Eric Hripko <eric@hripko.com>
Signed-off-by: Guillaume Lours <guillaume.lours@docker.com>
What this PR does / why we need it:
Introduce
no_cacheandpullattributes in the build section.Those allow to force a full rebuild from sources + sync with registry regarding the base image being used.
I don't expect those to be directly set by end-users in their compose.yml file, but getting them part of the compose model will allow Compose Implementations to offer
--no-cacheand--pulltocompose build(or equivalent) command.