-
Notifications
You must be signed in to change notification settings - Fork 6
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
Image for cartesi machine download #47
base: main
Are you sure you want to change the base?
Conversation
ff2e1da
to
1290f55
Compare
1290f55
to
6ec6549
Compare
@@ -0,0 +1,69 @@ | |||
name: machine-download | |||
on: | |||
workflow_call: |
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.
pretend to use this as a workflow? if not, remove this line
workflow_call: | |
workflow_call: |
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.
Are we going to use changesets here?
This was this way because of changesets
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'm not sure.
It won't hurt keeping it that, anyway.
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.
In any case what is missing here is a release strategy, either manual tagging or changesets.
What is the strategy of helm? Manual or automated?
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.
For the charts/, it's automated.
Tha tags are made by the CI after the charts hits the main
branch, we have a release via GH Pages, to host the helm legacy way, and also use ghcr.io for the OCI Reistry way of releasing helm charts.
I think we should deprecate the old way, and keep only the OCI Registry option.
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.
So does it make sense to let changesets take control of the “landing on main”, and delegate the release to a workflow call?
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'd have to test.
The ct
tool used to release already tags, won't it conflict with the changests tagging process?
FROM debian:bookworm-20230725 | ||
COPY --from=builder /go/bin/ipget /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.
FROM debian:bookworm-20230725 | |
COPY --from=builder /go/bin/ipget /usr/local/bin/ | |
FROM debian:bookworm-20230814-slim | |
COPY --from=builder /go/bin/ipget /usr/local/bin/ | |
RUN addgroup --system --gid 102 cartesi && \ | |
adduser --system --uid 102 --ingroup cartesi --disabled-login --no-create-home --home /nonexistent --gecos "cartesi user" --shell /bin/false cartesi | |
USER cartesi | |
ENTRYPOINT [ "ipget" ] |
6ec6549
to
74b072e
Compare
74b072e
to
68cdea1
Compare
This creates a docker image used to download cartesi machine snapshot from IPFS.
It uses the ipget go package.
This image will be used as an initContainer of a rollups node.