Bruno Bernardino•2mo ago

[Fresh] Docker build issue in CI after upgrading from v1 to v2

Alright, so I've been upgrading Fresh from v1 to v2 in bewCloud (https://bewcloud.com) for a while, and gave up a couple of times, but finally got everything working. It also builds in Docker locally without issues and everything seems to be fine. I really dislike the use of vite but couldn't get around it, unfortunately. Builds and tests got slower, but I guess that's the price for getting some progress. The app itself seems to have suffered no big problem. But I digress; the main issue I'm currently having, which is preventing a new release, is the fact that it fails to build a docker image in CI. It fails with a really weird error, about the deno.lock file:

...
#19 10.87 Task build vite build
...
#19 28.44 error during build:
#19 28.44 Error: Failed reading lockfile at '/app/deno.lock': Unsupported lockfile version ''. Try upgrading Deno or recreating the lockfile
#19 28.44     at __wbindgen_error_new (https://jsr.io/@deno/loader/0.3.6/src/lib/rs_lib.internal.js:1153:15)
...
------
Dockerfile:15
--------------------
  13 |     
  14 |     # Build fresh
  15 | >>> RUN deno task build
  16 |     
  17 |     RUN chown -R deno:deno /app /deno-dir
--------------------
ERROR: failed to build: failed to solve: process "/bin/sh -c deno task build" did not complete successfully: exit code: 1

...
#19 10.87 Task build vite build
...
#19 28.44 error during build:
#19 28.44 Error: Failed reading lockfile at '/app/deno.lock': Unsupported lockfile version ''. Try upgrading Deno or recreating the lockfile
#19 28.44     at __wbindgen_error_new (https://jsr.io/@deno/loader/0.3.6/src/lib/rs_lib.internal.js:1153:15)
...
------
Dockerfile:15
--------------------
  13 |     
  14 |     # Build fresh
  15 | >>> RUN deno task build
  16 |     
  17 |     RUN chown -R deno:deno /app /deno-dir
--------------------
ERROR: failed to build: failed to solve: process "/bin/sh -c deno task build" did not complete successfully: exit code: 1

You can see the current code in https://github.com/bewcloud/bewcloud with the Dockerfile at https://github.com/bewcloud/bewcloud/blob/main/Dockerfile and the CI action https://github.com/bewcloud/bewcloud/blob/main/.github/workflows/build-docker-image.yml#L46-L54 I'm not sure what to do, here. Docker builds locally, and the deno.lock file is there and is valid. If I remove it, it'll fail trying to resolve some dependencies (both locally and in CI).

13 Replies

fry69•2mo ago

I guess the Deno version in

FROM denoland/deno:ubuntu-2.5.1

FROM denoland/deno:ubuntu-2.5.1

may be outdated? I use

FROM docker.io/denoland/deno:latest

FROM docker.io/denoland/deno:latest

and sometimes even (for testing)

RUN deno upgrade canary

RUN deno upgrade canary

Bruno BernardinoOP•2mo ago

Thanks. There is a 2.5.2 released a couple of days ago, but that would not really explain it, and it's not really outdated. I want to stick it to a version I've tested. I just simplified the dockerfile and now get a core dump Fun.

fry69•2mo ago

Well, this works for me -> https://github.com/fry69/orw/blob/fresh-vite/orw-deno/Containerfile Except for the nodeModulesDir -> auto bug (should be manual to avoid messing with the said folder during build and at best all times currently, that is Deno bug), I not yet found a way to break or disappoint me.

Bruno BernardinoOP•2mo ago

Oooh. I just realized the error is actually only happening in linux arm64, not linux amd64. I'll try upgrading, maybe it was some more "behind-the-scenes" bug.

fry69•2mo ago

Side note: Instead of deleting stuff after copying it into the image, you can use a .dockerignore file -> https://github.com/fry69/orw/blob/fresh-vite/orw-deno/.dockerignore

Bruno BernardinoOP•2mo ago

Oh, it's not copied, but I "double check" there. It's already in the .dockerignore if you check it.

fry69•2mo ago

Well, it is bit overkill. The image gets created fresh and if you do not copy those things in, they are not there 🙂

Bruno BernardinoOP•2mo ago

So it's a quick command 😉

fry69•2mo ago

It is not just a quick command, you create another layer with it.

Bruno BernardinoOP•2mo ago

Ah, that's a good point Alright, it's still failing on arm64. I'm pretty sure this is indicative of some deeper bug in Deno, but I don't want to spend too much time looking into it right now. For now I'll just disable arm64 and keep amd64, for the new release.

fry69•2mo ago

Yep, I only have tested AMD64 and AARCH64 (Apple Silicon), not ARM64/Linux.

Bruno BernardinoOP•2mo ago

Same here, arm64 was in CI. I won't mark this as resolved to give the team an opportunity to look into it. I had to give up on it and revert the whole thing, too many issues with Fresh 2, I think mostly stemming from the fact it's leaning too much into the SPA-minded npm ecosystem: https://github.com/bewcloud/bewcloud/issues/99

fry69•2mo ago

Fresh is server fist, not SPA/client only/first, including version 2. Vite mostly enables faster startup and more granular chunks/bundles, also modern developer experience with HMR. Calling Fresh a SPA is IMHO ludicrous and hints there are major misunderstandings how this framework works. Regarding slow dev server startup: That is due to Vite being lazy. Vite dev delays transpiling/initializing until the first request comes in. There is little Fresh can do about this. You still get the upside of having access to HMR with the dev server. Otherwise you can of course transpile everything with vite build and use the production mode with deno serve _fresh/server.js also for testing. I actually prefer this to because there are still subtle problems with static assets in the dev server, which do not show up in the production build. In general having access to the Vite build infrastructure should make it more easy to build complex custom sites IMHO. (unless bugs in Fresh prohibit this, but those can get fixed, filing issues will help)

[Fresh] Docker build issue in CI after upgrading from v1 to v2

Did you find this page helpful?