feat: publish image to Docker Hub#1043
Conversation
|
We might want to rename this to |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1043 +/- ##
==========================================
- Coverage 70.38% 70.36% -0.02%
==========================================
Files 247 247
Lines 10867 10870 +3
==========================================
Hits 7649 7649
- Misses 2543 2544 +1
- Partials 675 677 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Could we have a shell inside the container? E.g using a alpine or debian base image?
I think it would fit for this use case, where we might want to have a shell for the CLI.
There was a problem hiding this comment.
Do you think it justifies the bloat? You could also just run the command by itself and mount a config from the host
There was a problem hiding this comment.
I just checked, the image would be ~26MB as is, using alpine as a base image would add another ~8MB.
There was a problem hiding this comment.
If its just about a shell, a different ko base image can provide this: https://github.com/apricote/releaser-pleaser/blob/c31e40d04bc9acc7b152d630cbdf3a6b2be0aebf/.ko.yaml#L6
I would be curious to hear where the shell would be useful though. In my mind users would run this with an alias and use their own shell for all things.
alias hcloud="docker run --rm -it -v ~/.config/hcloud/config.toml:/config.toml hetznercloud/cli:v1.xx --"
hcloud server list | grep ...@worr how do you intend to use this image?
There was a problem hiding this comment.
For example in a GitLab CI job, one could reference the image and run their CI tasks by having a shell in the image. Or a shady/dangerous k8s init container.
I think it makes sens to have a shell just because it is a CLI. Being able to run inside the image should also be considered (not always outside).
No strong opinion though.
There was a problem hiding this comment.
Yeah, I think your examples make sense. Maybe we should base it on alpine. I checked out the chainguard/busybox image and it seems to be quite large at 24MB.
There was a problem hiding this comment.
I think ko can use any base image, not only chainguard ones. Happy to try with a base alpine/busybox image
There was a problem hiding this comment.
But the fact that the image provides a basic shell should be documented. To make sure that we do not remove it in the future as an optimization :D
|
Personally, I plan on using it the way you describe, although in CI. I have no need for a shell.
9 may 2025 10:45:05 Julian Tölle ***@***.***>:
…
***@***.**** commented on this pull request.
----------------------------------------
In .goreleaser.yml[#1043 (comment)]:
> +kos:
+ - id: container-images
+ build: hcloud-build
+ main: ./cmd/hcloud/
+ repositories:
+ - hetznercloud/cli
+ platforms:
+ - linux/amd64
+ - linux/arm64
+ base_import_paths: true
+ labels:
+ org.opencontainers.image.source: https://github.com/apricote/hcloud-upload-image
+ tags:
+ - latest
+ - "{{.Tag}}"
+ ldflags:
+ - -s
+ - -w
+ - -X {{ .ModulePath }}/internal/version.version={{ .Version }}
+ - -X {{ .ModulePath }}/internal/version.versionPrerelease={{- if .IsSnapshot -}}dev+{{ .ShortCommit }}{{- end -}}
+ - -X {{ .ModulePath }}/internal/state/config.defaultConfigPathOverride=/config.toml
If its just about a shell, a different *ko* base image can provide this: https://github.com/apricote/releaser-pleaser/blob/c31e40d04bc9acc7b152d630cbdf3a6b2be0aebf/.ko.yaml#L6
I would be curious to hear where the *shell* would be useful though. In my mind users would run this with an alias and use their own shell for all things.
alias hcloud="docker run --rm -it -v ~/.config/hcloud/config.toml:/config.toml"
hcloud server list | grep ...
@worr[https://github.com/worr] how do you intend to use this image?
—
Reply to this email directly, view it on GitHub[#1043 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AABM4HP3LFZCQETQQ2EWVM325RTJBAVCNFSM6AAAAAB4WYSDWGVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDQMRXGUZDOMRXHA].
You are receiving this because you were mentioned.
[Imagen de rastreo][https://github.com/notifications/beacon/AABM4HJ75URT36HKGJLMAB325RTJBA5CNFSM6AAAAAB4WYSDWGWGG33NNVSW45C7OR4XAZNRKB2WY3CSMVYXKZLTORJGK5TJMV32UY3PNVWWK3TUL5UWJTVIRCSG4.gif]
|
There was a problem hiding this comment.
How does that work if the user extract the binary to use outside the container? Do we want to support this?
Or mount / inside the container (similar to network_mode: host but for the fs)?
There was a problem hiding this comment.
I agree that extracting the binary from the image would be problematic.
However I think mounting the entire FS into the container would be a bad idea because:
$HOMEwill still resolve to/home/nonrootso the config would be located at/home/nonroot/.config/hcloud/cli.toml- We should scope the possible file access as small as possible for security reasons
Maybe there is a way to detect if the binary is running inside a container dynamically during runtime? Or could we set HCLOUD_CONFIG somehow?
There was a problem hiding this comment.
I do not think we need to support extracting the binary explicitly. I like that we try to make defaults nicer for container users here.
ko unfortunately does not allow adding env variables to the image, so no possibility to do it through HCLOUD_CONFIG with ko.
If a user really wants to extract this binary, they can still set HCLOUD_CONFIG on their end to change the default.
apricote
changed the title
phm07
force-pushed
the
publish-docker-image
branch
from
4b46f77 to
8882519
Compare
<!-- section-start changelog --> ### Features - **load-balancer**: allow specifying network on create (#1013) - **context**: add unset commmand (#1017) - publish image to Docker Hub (#1043) ### Bug Fixes - allow getting resources with number as name - some list flags are not correctly parsed (#987) - **load-balancer**: allow certificate names in addition to IDs when creating/updating (#1026) - config option flags sometimes not parsed correctly (#1025) <!-- section-end changelog --> --- <details> <summary><h4>PR by <a href="https://github.com/apricote/releaser-pleaser">releaser-pleaser</a> 🤖</h4></summary> If you want to modify the proposed release, add you overrides here. You can learn more about the options in the docs. ## Release Notes ### Prefix / Start This will be added to the start of the release notes. ```rp-prefix ``` ### Suffix / End This will be added to the end of the release notes. ```rp-suffix ``` </details> Co-authored-by: releaser-pleaser <>
<!-- section-start changelog --> ### Features - **load-balancer**: allow specifying network on create (#1013) - **context**: add unset commmand (#1017) - publish image to Docker Hub (#1043) ### Bug Fixes - allow getting resources with number as name - some list flags are not correctly parsed (#987) - **load-balancer**: allow certificate names in addition to IDs when creating/updating (#1026) - config option flags sometimes not parsed correctly (#1025) <!-- section-end changelog --> --- <details> <summary><h4>PR by <a href="https://github.com/apricote/releaser-pleaser">releaser-pleaser</a> 🤖</h4></summary> If you want to modify the proposed release, add you overrides here. You can learn more about the options in the docs. ## Release Notes ### Prefix / Start This will be added to the start of the release notes. ```rp-prefix ``` ### Suffix / End This will be added to the end of the release notes. ```rp-suffix ``` </details> Co-authored-by: releaser-pleaser <>
4 participants
This PR adds CI to release OCI images to Docker Hub using ko.