-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Docker oven/bun:latest fails during bun install #9807
Comments
updating the system packages worked for me |
Hey @jonasfroeller, can you elaborate? How were you able to resolve the issue? Cheers |
Same issue when upgrading from bun v1.0.35 to v1.1.0 Interesting thing was that I had 2 projects refers the same action file, however 1 succeed w/ the installment & build, another always met the issue when on "bun install". Is there anything relates to the image itself? Cache maybe (just guess)? Succeed one (the image download phase): #5 [internal] load build context #6 [build_image 1/18] FROM docker.io/oven/bun:1.1.0-alpine@sha256:cd4b6bf06a182b2f79bdd92ebd28b9d95ad1c0939db7e1f7604821f841dbab3a Failed one (the image download phase): #5 [internal] load build context #6 [build_image 1/18] FROM docker.io/oven/bun:1.1.0-alpine@sha256:cd4b6bf06a182b2f79bdd92ebd28b9d95ad1c0939db7e1f7604821f841dbab3a |
Now it doesn't work anymore 👀. I experienced it similarly to @ShadowLeiPolestar. |
From the error message:
Note how In #9875, I added The next issue after this that might come up is a C/C++ compiler. If you're using |
I added
|
The problem seems to be with my devDependencies. But as
|
As a workaround, I hide the devDependencies:
|
I noticed that there were some changes made to the On April 4th, Could you please provide some context for these changes? It would be helpful to understand the reasoning behind the addition and subsequent removal of Thank you for your time and contributions to this project. |
@thienandangthanh I added @Electroid removed |
@Jarred-Sumner I appreciate your efforts in maintaining the efficiency and effectiveness of this project. Keep up the great work! |
I've encountered a similar error to the one reported in this issue. The error seems to be related to the Interestingly, when I use the Docker image Here's the error log with bun 1.1.2 for reference:
The error message suggests that I hope this additional information can assist the Bun team in diagnosing and resolving the issue. Please let me know if there's any other information I can provide to help. |
To workaround the issue I've been using FROM --platform=$BUILDPLATFORM node:lts-slim AS base
WORKDIR /app
COPY . .
RUN npm i -g bun
FROM base AS all-deps
RUN bun install
FROM base AS prod-deps
RUN bun install --production
FROM all-deps AS build
ENV NODE_ENV=production
RUN bun --bun run astro build
FROM oven/bun:alpine AS runtime
COPY --from=build /app/dist dist
COPY --from=prod-deps /app/node_modules node_modules |
Thanks for the suggestion @jaredLunde, switching my builder image from I was getting the same errors as @tapz above while installing
Explicitly installing In my case though |
Unfortunately I'm getting the exact same python error as when using the bun base image for this suggestion
|
@smaccoun |
Ah yes I didn't read carefully enough. Thanks for pointing that out @thienandangthanh. I do have it working now I'm a bit confused by this comment @Jarred-Sumner
Seems like a critical dependency to make the docker image work with bun build, so why not include it? I supposed one reason might be that some might just be using bun for it's runtime, and not to actually build? That would make sense if the reason. I wonder though about then maybe have two official Dockerfiles ( Also just my 2 cents here, but part of what I love about Bun ux is things seem to just work. I don't have to spend tons of time configuring things. Building your backend on docker is going to be a very common use case. Yet here i have to say I feel like there is an odd (almost universal) developer obsession with container sizes, bundle sizes, etc. In many instances it seems like we forego good dx to save some size that will have 0 perceivable downstream impact. To me it's effectively a classic case of premature optimization. I understand the general sentiment to not make a container any larger than it has to be, and to leave it up to the user to add what they need, but in this case how much does Python3 really affect anyone's setup? I'm not strongly opinionated on this, just something to consider. I get many might object to this, so there's probably no clear answer and I'd understand whatever direction you decide to go. I certainly don't regard @Electroid decision to remove it as a bad decision by any stretch - it may be the popular thing to do amongst many developers and therefore the right thing from a bun perspective. I guess I just sometimes want to push back against the whole developer community and the seemingly endless desire to squeeze size out of everything, even when it seems like the tradeoffs are quite lopsided |
With the bun 1.1.8 release, my problem is gone. Thanks to node:zlib brotli support in pull request #10722. Now I can use the Docker image |
Still seems to be an issue I had to downgrade to 1.0.x to get it working:
|
For those using the default image (based on debian), this worked as a temporary workaround for the missing python3 err: RUN apt update && apt install python3 python3-pip make g++ -y |
What version of Bun is running?
1.1.0
What platform is your computer?
Linux 5.15.0-101-generic aarch64 aarch64
What steps can reproduce the bug?
build a docker file similar to this
What is the expected behavior?
docker builds successfully
What do you see instead?
Additional information
No response
The text was updated successfully, but these errors were encountered: