white window after update

[serjsv87]

after the update do not compile correctly files, and did not find what the problem as a temporary solution went into the container web further into the folder

` cd /app/public/assets/frontend

` and created two symlinks (the names I looked through the conosl in the browser where the browser tries to address and what files it did not find. and what files I had).

ln -s main.12201f048e48aade.js main.d284824e30451deb.js 
ln -s runtime.6aa68e2854e759f5.js runtime.eda122562b2793d9.js

[kahrpatrick]

I am struggling with a very similar issue on a fresh install. After pre-compiling the assets, I had to rebuild the frontend asset manifest file with bundle exec assets:rebuild_manifest.

I am still trying to find out what I was was missing from the setup instructions since it didn't work as described in the guide.

[serjsv87]

I tried to rebuild it via bundle but it didn't work through npm. I probably could have done something else, but I didn't have enough time. I found a temporary fix

[dand-oss]

I tried to rebuild it via bundle but it didn't work through npm. I probably could have done something else, but I didn't have enough time. I found a temporary fix

How did you solve it?

[serjsv87]

I looked through my browser to see what files are being requested, and symlinked to those files.

ln -s main.12201f048e48aade.js main.d284824e30451deb.js 
ln -s runtime.6aa68e2854e759f5.js runtime.eda122562b2793d9.js

[abrmichael]

The problem is the new volume called assets. Removing it solves the problem. Since the proxy, that also uses that volume, are configured to proxy everything upstream the local files are never accessed anyway.

See https://github.com/opf/openproject-deploy/commit/dbccaae404b977fdd1e1f1e36ded12b7a1e8207d#r143825032

[infocillasas]

@abrmichael I have the same exact problem (white page after update) Do you mean that removing the "assets" directory inside /var/lib/docker/volumes/compose_assets/_data/ should resolve the issue ?

[estan]

I got a similar issue when upgrading to 14.2.1 just now.

The OpenProject page after login is requesting /assets/frontend/runtime.e9ffdf40b4330a46.js and /assets/frontend/main.63f41c09d0497c69.js, but that is not the name of those files within the assets volume (shared between proxy and web service). Instead they are called:

orexplore@oden:~$ sudo ls /var/lib/docker/volumes/compose_assets/_data/assets/frontend/ | egrep "runtime|main"
main.19d5f6267de079ae.js
runtime.48279d65f5a2f7dc.js
orexplore@oden:~$

[estan]

@abrmichael Ah now I saw your comment and also https://github.com/opf/openproject-deploy/commit/dbccaae404b977fdd1e1f1e36ded12b7a1e8207d#r143825032

That must be what happened to me. What is the solution to get out of this?

[estan]

Ah, removing the volume sorts it out.

So @infocillasas, I believe what @abrmichael meant was something like:

docker-compose down
docker rm compose_assets
docker-compose up -d

I.e. remove the volume completely, then bring up the services again, which will recreate the volume.

At least this solved the issue for me.

I guess this will be my go-to way when upgrading for now, until some better solution is found.

[serjsv87]

yeah, I also deleted the image and it worked for me.

[abrmichael]

The easiest way is to just comment out the volume mount for the web container. In docker-compose.yml;

  web:
    <<: *app
    command: "./docker/prod/web"
    networks:
      - frontend
      - backend
    depends_on:
      - db
      - cache
      - seeder
    labels:
      - autoheal=true
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080${OPENPROJECT_RAILS__RELATIVE__URL__ROOT:-}/health_checks/default"]
      interval: 10s
      timeout: 3s
      retries: 3
      start_period: 30s
    volumes:
      - "${OPDATA:-opdata}:/var/openproject/assets"
#      - assets:/app/public

That way it's easy to activate it again as soon as the bug is fixed.

[infocillasas]

Thanks a lot. Works perfectly now.

[Kharonus]

Yes, updating the assets was an issue after adding support for the slim image tag for the compose stack.

As mentioned, a workaround was removing the assets and upping the stack again.

We also had a BUG ticket about that.

I the PR #83 we removed the volume ourselves, so that the assets are no longer served statically through the proxy, but the requests are piped through to the app container.