Skip to content
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

ci: fix platform of the target docker image #9861

Closed
wants to merge 1 commit into from

Conversation

galargh
Copy link
Contributor

@galargh galargh commented May 8, 2023

@lidel As per https://www.docker.com/blog/faster-multi-platform-builds-dockerfile-cross-compilation-guide/, shouldn't the final image build skip the --platform arg so that the end image is built for the requested target platform?

closes #7541
closes #4584

@galargh galargh requested a review from lidel May 8, 2023 18:17
Copy link
Member

@lidel lidel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if this helps with #9901.

Don't have ARM at hand to test, would have to dust-off a raspberry Pi or setup QEMU to confirm – parking until me or someone else has time to confirm.

@galargh
Copy link
Contributor Author

galargh commented Jun 29, 2023

Oh nice, I'll have it tested tomorrow and get back to you.

Copy link
Member

@lidel lidel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@galargh I've tested this approach (removal of --platform from second FROM) in simpler but similar Dockerfile from bifrost-gateway, and it was not enough.

We have some legacy overengineering for building tini and su-exec (we literally build su-exec from C code and that is unable to leverage golang tooling for cross-compilation).

Good news

I was successful in cleaning up that in ipfs-inactive/bifrost-gateway#159, and did a smoke test on old Rpi4 (ARM64) and it runs fine, while keeping the similar size.

Bad news

Kubo's Dockerfiles has more moving pieces.

I think we could try to do the same thing here, but:

  • I don't know if we can set CGO_ENABLED=1 and remove dependency on glibc
    • maybe @Jorropo or @aschmahmann know if this is feasible? will this break plugins?
    • if we need to keep glibc, perhaps we can install necessary lib, eg.g RUN apk add --no-cache gcompat ?
  • we seem to install and copy fuse, libdl, libssh and libcrypto from first stage to second
    • I suspect we could remove it from first stage, and install arch-specific libraries in second one

@galargh galargh closed this Aug 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants