-
-
Notifications
You must be signed in to change notification settings - Fork 624
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
added dockerfile and multiarch build job in goreleaser workflow. fixe… #1868
base: main
Are you sure you want to change the base?
added dockerfile and multiarch build job in goreleaser workflow. fixe… #1868
Conversation
file: ./Dockerfile | ||
push: true | ||
tags: | | ||
go-task/task:latest |
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 this workflow is triggered on tag creation, it would be a good idea to tag the created image with the version tag that was created in git. That way we can have matching tags for the docker images and the git repo.
We can still leave in a latest
tag, but I consider actual version tags to be a requirement to properly use this image
|
||
WORKDIR /app | ||
|
||
RUN /app/install-task.sh -b /usr/local/bin |
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.
My main gripe with this is that is is, at least as far as I understand, quite impossible for docker to cache any layers to speed up builds.
@@ -0,0 +1,9 @@ | |||
FROM golang:1.23.2-alpine |
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 would technically only be the build
stage. For the final "production" stage, there is no need to have golang
as a base. We could do alpine
or something smaller
|
||
docker: | ||
runs-on: ubuntu-latest | ||
needs: goreleaser |
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.
any reason we need to wait for the goreleaser
job? I don't see any hard dependency and we could save some time by executing these jobs in parallel
@maehldom is there any reason for going with this approach instead of going with |
…s #1801