fix: reduce Docker image size

[stumpylog]

Consider this a simplified initial base that #637 could build upon for the frontend in particular.

The main change here is to build the monolith binary in a seperate stage and copy it to the final stage. This means all users do not get a complete install of Rust, build-essential, etc, as none of that is required to run the binary.

This shaves about 40% off the image size:

linkwarden                                   local            49fb760b02e4   22 seconds ago   2.82GB
ghcr.io/linkwarden/linkwarden                latest           3b3bee162793   9 days ago       4.35GB

[CLAassistant]

All committers have signed the CLA.

[theAkito]

https://github.com/linkwarden/linkwarden/pull/637

[stumpylog]

As noted, this is a different approach, which has less changes and can provide a base for that PR to work from.

[daniel31x13]

Hey just built this and looks like the image size is 3.45gb instead.

Btw can you replace the yarn playwright install command to install chromium only?

[stumpylog]

That's odd. What are you viewing in? What command did you build with?

I can look at the other update tomorrow. Would you want it in this pr or separate?

[daniel31x13]

It's Docker Desktop. Also no need for a separate pr...

[stumpylog]

I'm not familiar with Docker Desktop, so I don't know what it may be doing. Perhaps showing all arches, or uncompressed size. I just do:

$ docker image ls | grep link
linkwarden                                                                               local       599e3045f3de   2 minutes ago   1.86GB
ghcr.io/linkwarden/linkwarden                                                            latest      3b3bee162793   2 weeks ago     4.35GB

That's with the change for installing just Chromium.

[daniel31x13]

Thanks, gonna completely remove the image and try again. Maybe there were some stuff from before that I haven't deleted, hence the extra file size...

[daniel31x13]

Ok this has officially shrunken down the image size (while maintaining the functionality).

But the image size is still different from yours though:

linkwarden-linkwarden                 latest            7be96542b60f   3 minutes ago   2.65GB

[stumpylog]

Strange, I have no ideas on that. I'd be curious to see what the CI built image size is. I've triggered a build here: https://github.com/stumpylog/linkwarden/actions/runs/10398194333

[daniel31x13]

@stumpylog just a side-note that the build might take up to 2 hours (not related to Linkwarden)...

I'll be getting to this tmw...

[stumpylog]

I've noticed. If the plan is to support amd64 and arm64 only, the released monolith binaries could be downloaded instead of built

[daniel31x13]

Btw just noticed the NEXT_PUBLIC_ environment variables aren't being applied to the client side properly, for example set NEXT_PUBLIC_EMAIL_PROVIDER=true and you'll notice it doesn't ask for an email when you're trying to signup:

[stumpylog]

I don't think that can be related to this. The building and running of the frontend remains unchanged.

I also don't get asked for an email if I set NEXT_PUBLIC_EMAIL_PROVIDER with the current released version.

[daniel31x13]

I meant if you build it locally instead of using the actual image:

version: "3.5"
services:
  postgres:
    image: postgres:16-alpine
    env_file: .env
    restart: always
    volumes:
      - ./pgdata:/var/lib/postgresql/data
  linkwarden:
    env_file: .env
    environment:
      - DATABASE_URL=postgresql://postgres:${POSTGRES_PASSWORD}@postgres:5432/postgres
    restart: always
    build: .
    ports:
      - 3000:3000
    volumes:
      - ./data:/data/data
    depends_on:
      - postgres

[stumpylog]

I'm not following. Setting the below doesn't ask for an email on signup with any image, built local or the 2.6.2 tag:

  linkwarden:
    # image: linkwarden:local
    image: ghcr.io/linkwarden/linkwarden:v2.6.2
    container_name: linkwarden
    environment:
      DATABASE_URL: "postgresql://linkwarden:linkwarden@linkwarden-db:5432/linkwarden"
      NEXT_PUBLIC_EMAIL_PROVIDER: "true"

I tested some other settings from index.ts and they set correctly, such as NEXT_PUBLIC_AUTHELIA_ENABLED: "true" produces this:

I can't say why NEXT_PUBLIC_EMAIL_PROVIDER differs, but I can't see how this PR affects a fronted thing. NEXT_PUBLIC_EMAIL_PROVIDER is properly set in the environment, per a simple printenv

[daniel31x13]

Strange, gonna see if I can sort things out...

Also the reason you see the Authelia button is because that button is being conditionally rendered using server side rendering instead of client side.

[daniel31x13]

Hey sorry for the late response, there were so many WIP features and I needed to merge them before I can get to this. So looks like this was working similar to how the main branch is right now and no breaking changes should be happening...