Skip to content
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

Allow setting KO_DOCKER_REPO in .ko.yaml #627

Closed
embano1 opened this issue Mar 1, 2022 · 12 comments
Closed

Allow setting KO_DOCKER_REPO in .ko.yaml #627

embano1 opened this issue Mar 1, 2022 · 12 comments
Assignees

Comments

@embano1
Copy link
Contributor

embano1 commented Mar 1, 2022

Based on a Twitter conversation, it was raised whether KO_DOCKER_REPO should also be a configuration option in .ko.yaml (mainly for consistency purposes).

IMHO since this is not a build but publish option, it might have to go in PublishOptions parsing (related: #351).

@developer-guy
Copy link
Collaborator

will you work on that @embano1? 🙋🏻‍♂️

@developer-guy
Copy link
Collaborator

@imjasonh maybe we can do both #626, WDYT, if you agree, I'm willing to do this one too

@imjasonh
Copy link
Member

imjasonh commented Mar 2, 2022

Sure!

My only real question is what do we want it to look like in .ko.yaml? A new top-level repo: field? Something else? Give me your ideas!

@embano1
Copy link
Contributor Author

embano1 commented Mar 4, 2022

Initially I thought a top-level string:string field would work, e.g. imageRepository: myrepository.somewhere.out.

Then I thought, how likely is it that multiple images should be pushed to different registries/locations? I.e. something similar we do with baseImageOverride and build for different binaries?

@developer-guy
Copy link
Collaborator

hello @embano1, you can keep up the process from here, please feel free to add your comments to the PR. 🙋🏻‍♂️

@imjasonh
Copy link
Member

imjasonh commented Mar 4, 2022

Then I thought, how likely is it that multiple images should be pushed to different registries/locations?

ko doesn't support this at all today. In the spirit of not scope-creeping this, I'd like to maintain something like the current behavior, and just push to a single repo per ko invocation.

@laurentsimon
Copy link
Contributor

Hw about tags? Can they also be included in the .ko.yaml file to tag each build individually? Shall I create a tracking issue for this or there's a reason for not doing that?

@imjasonh
Copy link
Member

What's your use case for wanting each image in a ko resolve to get different tags? 🤔

The typical use case for tags is associating images with a release (:v1.2.3), which generally means all the images in a set of images should have the same tag.

@laurentsimon
Copy link
Contributor

laurentsimon commented Apr 14, 2022

oops, sorry. I'm interested in different tags for ko publish only. I was hoping I could generate/push multiple images with distinct tags.

@imjasonh
Copy link
Member

oops, sorry. I'm interested in different tags for ko publish only. I was hoping I could generate/push multiple images with distinct tags.

ko build only builds one image today (at least until #644 lands), and even when it doesn't I think I'd like to recommend that all invocations produce the same tags, for more or less the same reason as ko resolve does today.

You can already ko build ./ -t foo -t bar to produce one image with both :foo and :bar, but I don't think I want to support any situation where tags are selectively applied to images without a strong indication of the use case.

@developer-guy
Copy link
Collaborator

kindly ping @imjasonh

@github-actions
Copy link

github-actions bot commented Aug 8, 2022

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Keep fresh with the 'lifecycle/frozen' label.

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

Successfully merging a pull request may close this issue.

4 participants