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

Make KO_DOCKER_REPO configurable #1

Closed
embano1 opened this issue Apr 29, 2021 · 4 comments
Closed

Make KO_DOCKER_REPO configurable #1

embano1 opened this issue Apr 29, 2021 · 4 comments

Comments

@embano1
Copy link

embano1 commented Apr 29, 2021

It would be nice to have KO_DOCKER_REPO being part of the inputs, e.g.

- uses: imjasonh/setup-ko@v0.3
  with:
    version: v0.8.0
    KO_DOCKER_REPO: kind.local # later passed/injected as env var

This would avoid an additional step for the user to export the variable.

@imjasonh
Copy link
Member

imjasonh commented Apr 30, 2021

With the current version if a user wants to set KO_DOCKER_REPO to something else, they can, we just give a default:

steps:
- uses: imjasonh/setup-ko@v0.3
- run: KO_DOCKER_REPO=kind.local ko publish ./

or:

steps:
- uses: imjasonh/setup-ko@v0.3
- env:
    KO_DOCKER_REPO: kind.local
  run: ko publish ./

edit: but not this:

env:
  KO_DOCKER_REPO: kind.local
steps:
- uses: imjasonh/setup-ko@v0.3
- run: ko publish ./

(setup-ko seems to overwrite the workflow-wide env in this case)

That might still be confusing, since if a user forgets to set it for one step it'll revert back to KO_DOCKER_REPO=ghcr.io/....

It might make more sense to take an input to disable the ghcr-setting at all, so it doesn't login and doesn't set KO_DOCKER_REPO at all. At least that way if you forget to set it it'll fail loudly instead of silently "helpfully" defaulting to ghcr.

@embano1
Copy link
Author

embano1 commented Apr 30, 2021

Thx. Instead of disabling as an option, which option do you think is most common?

  • Use your action and set/customize that env variable as part of the job step and export it for downstream jobs
  • Use your action and set/customize that env variable locally (action) and make it available for downstream jobs via id.output reference syntax
  • Define this var in a global env section, honored by this action if defined, otherwise overwrite and export with a default

I think inject as env (3) would probably be most flexible as it can be easily used elsewhere, eg to later pull this image etc by globally defining it (job vs action-level).

@imjasonh
Copy link
Member

Yeah I think I like not setting it if it's already set when it gets to the action. That's easy to describe and easy to implement.

Thanks for the suggestion!

@imjasonh
Copy link
Member

imjasonh commented May 1, 2021

Fixed in https://github.com/imjasonh/setup-ko/releases/tag/v0.4

@imjasonh imjasonh closed this as completed May 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants