-
Notifications
You must be signed in to change notification settings - Fork 408
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
feat: globalEnvs for KO_DOCKER_REPO, annotations and labels for the image config based on build ids #632
Conversation
Codecov Report
@@ Coverage Diff @@
## main #632 +/- ##
==========================================
- Coverage 50.41% 50.17% -0.25%
==========================================
Files 44 44
Lines 3338 3392 +54
==========================================
+ Hits 1683 1702 +19
- Misses 1445 1475 +30
- Partials 210 215 +5
Continue to review full report at Codecov.
|
Annotations map[string]string `yaml:",omitempty"` | ||
Labels map[string]string `yaml:",omitempty"` |
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.
Should these just go in Config
alongside Env
etc.? It seems like a meaningless separation.
The only problem with that is if goreleaser adds a Labels
or Annotations
field to its config, we'd have a different meaning. I'm starting to really regret copying goreleaser's config so closely. 😢
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.
IMHO, we should separate them from a build because these are related to the image we provide at the end of that build. So, it might cause a bit more confusion if we put them into the Config section. In the current design, users should match the id fields of the builds and images sections to be able to define labels and annotations per image related to that build, WDYT?
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.
Oh I see, I was confusing build.env
(what envs to set when we go build
) vs image.env
(what envs to set in the resulting image).
In that case, yeah, I agree we should have a separate image config struct with labels/annotations.
We should also use this to fix #633, with a top-level defaultImageConfig: { }
option, that gets overridden by more specific images:
and both get overridden if there's a conflicting --image-label
specified.
WDYT?
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.
Oh yeah, we should apply some kind of prioritization between them, that makes a lot of sense 🙋🏻♂️
Here are the prioritization rules:
- The most important one is --image-label, if there is a conflict between others, we should use the defined one by the --image-label flag.
- The second important one is the images section within the .ko.yaml, so, if we specify the more specific one inside of that section, we should override the defaultImageConfig.
- The defaultImageConfig has the lowest priority among others. We should use the values within the defaultImageConfig unless others (images:, --image-label) do not specify any values at all.
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.
it should be okay @imjasonh 🙋🏻♂️
pkg/commands/apply.go
Outdated
@@ -96,7 +96,7 @@ func addApply(topLevel *cobra.Command) { | |||
if err != nil { | |||
return fmt.Errorf("error creating builder: %w", err) | |||
} | |||
publisher, err := makePublisher(po) | |||
publisher, err := makePublisher(po, bo.Envs) |
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.
Passing a build option to makePublisher
is a bit of a smell... Should it be a publish.Option
? 🤔
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.
Yeah, I've updated the code like this 🙋🏻♂️
pkg/commands/options/build.go
Outdated
ImageConfigs map[string]build.ImageConfig `yaml:",omitempty"` | ||
|
||
// Envs stores the global environment variables from `.ko.yaml`. | ||
Envs map[string]string `yaml:",omitempty"` |
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.
(grr GitHub ate my comment here, twice!)
This might be confusing because it kinda sounds like these envs will end up getting set in the resulting image(s), like builds[id].env
does today.
At the same time, we've only gotten the request so far to set KO_DOCKER_REPO
if the env is unset. Maybe just make this dockerRepo string
and use it if it's set and KO_DOCKER_REPO
isn't.
(We'll also need to update docs, and the error message when KO_DOCKER_REPO
is not set)
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.
okay, makes sense to me, I've updated the code according to your comments 🙋🏻♂️
if bo.DockerRepo != "" { | ||
po.DockerRepo = bo.DockerRepo | ||
} |
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.
Bleh, this also doesn't feel right. Sorry to keep moving things around on you, I'm struggling to find a good way to express this without having multiple copies of this floating around.
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.
What about creating an overrider function to set and pass some variables from builder to publisher struct?
makeOverrider(bo, po)
I'm not sure if overrider
is the right word but used it as a placeholder.
@@ -122,6 +122,14 @@ func gobuildOptions(bo *options.BuildOptions) ([]build.Option, error) { | |||
opts = append(opts, build.WithConfig(bo.BuildConfigs)) | |||
} | |||
|
|||
if bo.ImageConfigs != nil { | |||
opts = append(opts, build.WithImageConfig(bo.ImageConfigs)) |
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.
What if WithImageConfig
just handled nil
? Then we could opts = append(opts, build.WithImageConfig(bo.ImageConfigs))
no matter what. (same with defaultImageConfig
)
…mage config based on build ids Signed-off-by: Batuhan Apaydın <batuhan.apaydin@trendyol.com> add annts Signed-off-by: Furkan <furkan.turkal@trendyol.com> Signed-off-by: Batuhan Apaydın <batuhan.apaydin@trendyol.com> add test Signed-off-by: Furkan <furkan.turkal@trendyol.com> Signed-off-by: Batuhan Apaydın <batuhan.apaydin@trendyol.com>
kindly ping 🙋🏻♂️ |
kindly ping @imjasonh 🙋🏻♂️ |
kindly ping @imjasonh |
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 looks okay to me. I don't terribly love the duplication of DockerRepo
in build options and publish options, but 🤷 I don't have any better ideas either.
@jonjohnsonjr how do you feel?
(And as always, sorry this sat for so long, that's entirely my fault)
waiting for your feedback @jonjohnsonjr before resolving the conflicts 🙋🏻♂️ |
This Pull Request is stale because it has been open for 90 days with |
Fixes #627 #626 #633
Signed-off-by: Batuhan Apaydın batuhan.apaydin@trendyol.com
I tested it with the following .ko.yaml
.ko.yaml
The result of this build is
devopps/ko:latest
image.So, if you run
crane manifest devopps/ko:latest
, you will see the following contentcrane manifest devopps/ko:latest
Also, you should see the labels:
crane config devopps/ko:latest