Add workflow to build and consume kopia binary in kanister-tools #1611
Conversation
Signed-off-by: Ankit Jain <ankitjain.meone@gmail.com>
|
Thanks for submitting this pull request 🎉. The team will review it soon and get back to you. If you haven't already, please take a moment to review our project contributing guideline and Code of Conduct document. |
…er tools Dockerfile
…e Kanister tools Dockerfile" This reverts commit 5434adb.
|
Working on a follow-up PR to automate the process : #1620 |
ankitjain235
force-pushed
the
kopia-image-update
branch
from
0502664
to
35e8e26
Compare
| # Build kopia binary from specific commit | ||
| RUN git checkout ${kopiaBuildCommit} | ||
| # Refers to goreleaser/goreleaser:v1.11.2 | ||
| COPY --from=docker.io/goreleaser/goreleaser@sha256:b13418f20019fffb29797aff3d03f5e9ca84cea93634f4169a7ed603a95ab198 \ |
There was a problem hiding this comment.
Is this the same goreleaser version used during release?
There was a problem hiding this comment.
In kanister build, we are using goreleaser/goreleaser:v1.2.4. It's about 8 months old when we last updated it.
There was a problem hiding this comment.
@ankitjain235 (@pavannd1) Can this be simplified?
For example, does goreleaser need to be used here?
It is possible to build kopia directly. For example, see https://github.com/kastenhq/kopia/blob/publish/docker/kopia-alpine/Dockerfile
A few questions:
- is is necessary to build a container image for kopia? or would it suffice to build the binary, say as part of building the tools image?
- is it necessary to build the image or binary every time? or can it be cached and reused, and only rebuilt when the kopia version / commit id changes?
There was a problem hiding this comment.
We used goreleaser just so that we can build the kopia binary the way it is done upstream and we won't have to worry about changing the command if it needs to be changed any time as per change upstream.
In a follow-up PR(#1620) that is WIP, I am adding an action that can be manually triggered whenever we want to build kopia. I kept the process to build a container image for kopia only for this use case. That way, we would only build Kopia image when it's required. Making it as a part of kanister-tools image would result in re-building the binary in scenarios I tried out.
pavannd1
requested review from
akankshakumari393 and
viveksinghggits
and removed request for
viveksinghggits and
akankshakumari393
| # Build kopia binary from specific commit | ||
| RUN git checkout ${kopiaBuildCommit} | ||
| # Refers to goreleaser/goreleaser:v1.11.2 | ||
| COPY --from=docker.io/goreleaser/goreleaser@sha256:b13418f20019fffb29797aff3d03f5e9ca84cea93634f4169a7ed603a95ab198 \ |
There was a problem hiding this comment.
@ankitjain235 (@pavannd1) Can this be simplified?
For example, does goreleaser need to be used here?
It is possible to build kopia directly. For example, see https://github.com/kastenhq/kopia/blob/publish/docker/kopia-alpine/Dockerfile
A few questions:
- is is necessary to build a container image for kopia? or would it suffice to build the binary, say as part of building the tools image?
- is it necessary to build the image or binary every time? or can it be cached and reused, and only rebuilt when the kopia version / commit id changes?
|
@julio-lopez good questions 👍🏼 We have discussed those improvements and will iterate on this. It was crucial to get this in to unblock the upgrades 💯 |
Signed-off-by: Ankit Jain ankitjain.meone@gmail.com
Change Overview
This PR adds functionality to build and push kopia image to ghcr.io/kanisterio.
When a PR merges, we update the image.
Current commit corresponds to v0.11.3 commit upstream.
Pull request type
Please check the type of change your PR introduces:
Issues
Test Plan