-
-
Notifications
You must be signed in to change notification settings - Fork 686
chore: Distribute as docker image #1875
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
base: main
Are you sure you want to change the base?
Conversation
7ee6ad0
to
1795ad5
Compare
What do you think about this implementation? I moved to using I also added some documentation about the changes, though I decided to keep it rather minimal. Not sure about the I also modified the goreleaser to only push to GHCR (initially it was configured to push to docker.io as well). P.S. Ignore the devcontainer file, that was only for my local testing. I will drop that commit once this PR is ready |
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.
We should probably also add additional tags for latest
, 3
, 3.40
etc.
.goreleaser.yml
Outdated
use: buildx | ||
dockerfile: Dockerfile | ||
extra_files: | ||
- completion/bash/task.bash |
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.
Direct usage of these files is deprecated.
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 damn, I completely missed that. Will fix!
FWIW, they still seem to be referenced throughout the goreleaser
config. If I understand correctly, the brew installer also uses them as well as the nfpms?
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 unfortunately, they are still used in a few places. This is why we deprecated them instead of removing them. We need to slowly remove the references to them. We could probably still add completions to the image by writing a .bashrc
during the build and using the new method
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.
I thought about generating the completions in the container, but then I decided against it.
It doesn't make much sense to generate the bash completions given the image is based on scratch IMHO, and even then, if we generate and include one set of completions we might as well generate all.
I think that, given the completions can be generated from the binary, it is just as simple to add a RUN
command in your dockerfile to set up your required completions.
There are already instructions for generating the completions so that should have it covered. At the end of the day, the container image is a means to distribute the binary, right?
Let me know what you think!
c05b218
to
4ca75d4
Compare
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.
Haven't attempted to build it yet, but added some comments for now.
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.
Hi @mircea-pavel-anton, this looks good!
It still misses the login step, right? Anything needed from my part to move this forward?
89a14a7
to
48c8985
Compare
Co-authored-by: Andrey Nering <[email protected]>
Co-authored-by: Andrey Nering <[email protected]>
48c8985
to
e09b7dc
Compare
Hi @andreynering ! Sorry for the delay, I've been a bit busy. I have added the login step and rebased my branch. It should be all good now |
@reneleonhardt thanks for the feedback! I added your suggestions to this PR and made sure my branch is updated @andreynering @pd93 anything else I can help with to move this forward? I am not 100% sure on that |
@@ -0,0 +1,3 @@ | |||
FROM gcr.io/distroless/static-debian12:nonroot | |||
COPY task /task | |||
CMD ["/task"] |
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.
Probably better if you would actually run this container for whatever reasons 😅
CMD ["/task"] | |
ENTRYPOINT ["/task"] |
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.
Since its based on distroless, would you ever run it by itself though? I think this would maybe make sense with a usable base. Dunno
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.
You could use the CLI / help at least if you're curious 😉
::: | ||
|
||
```Dockerfile | ||
FROM ubuntu:22.04 |
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.
Back to the future... 🚀
FROM ubuntu:22.04 | |
FROM ubuntu:24.04 |
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.
At this point we might as well put latest
as a tag rather than keep updating the example, I'd say.
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.
Of course, it's just an example anyway. Convention is not to use latest, the user should override anyway.
```Dockerfile | ||
FROM ubuntu:22.04 | ||
# ... | ||
COPY --from=ghcr.io/go-task/task:v3.40.2 /usr/local/bin/task /usr/local/bin/task |
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.
Let's use the nice new "shortcut"
COPY --from=ghcr.io/go-task/task:v3.40.2 /usr/local/bin/task /usr/local/bin/task | |
COPY --from=ghcr.io/go-task/task /task /usr/local/bin/task |
@@ -0,0 +1,3 @@ | |||
FROM gcr.io/distroless/static-debian12:nonroot | |||
COPY task /task |
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.
I don't know if the build is "hardened", let's just make sure that users can read and execute automatically
COPY task /task | |
COPY --chmod=555 task /task |
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.
IMO this isn't really necessary. We started under the assumption this is a means to distribute the binary. You can just copy it from this container and apply whatever permissions you want on it in your container
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.
Just a suggestion. Most users don't know or care about permissions, this argument would make it easier for everyone, it's a binary after all.
This is currently a WIP to solve #1801
Some notes
I chose debian as a base for the docker image instead of alpine, for example, such that I can load the bash completion
I set the workdir to
/workspace
to facilitate mounting volumes into the container via ad-hoc docker commands, i.e.:I set the cmd instead of the entrypoint to the
task
executable such that it is easier to just exec into the container like so:docker run -it -v $PWD:/workspace ghcr.io/go-task/task:v3.39.2-amd64 /bin/bash
the current implementation pushes both to dockerhub and ghcr.io
the current implementation pushes:
ghcr.io/go-task/task:v3.39.2
)ghcr.io/go-task/task:v3.39.2-amd64
)ghcr.io/go-task/task:latest
)TODO