Fix Docker Compose setup

[Avalancs]

The problem

Tried self-hosting with docker compose, following the documentation and tinkering, but there are some issues with the .env.example file and docker-compose.yml.

1. When I tried the v3.9.0 tag the backend would not start up because of the OIDC environment variables

OIDC_CLIENT_ID=
OIDC_CLIENT_SECRET=
OIDC_DISCOVERY_URL=http://oidc.localhost:5556/dex/.well-known/openid-configuration

I tried clearing out the OIDC_DISCOVERY_URL variable but the backend would still try to connect to an OIDC server and not start up. In the end I had to comment out these variables in the docker-compose.yaml file itself so it would start up properly.

2. I'm trying this on the master branch now, and all these variables are commented out by default in docker-compose.yml, so even if someone was to follow the documentation and fill out these variables in the .env file it wouldn't do anything.

Another issue that I experience on the master is that the backend cannot find Postgres. The connection url is baked into docker-compose.yml as

SCRUMLR_SERVER_DATABASE_URL: "postgres://scrumlr:${POSTGRES_PASSWORD}@postgres:5432/scrumlr?sslmode=disable"

Which assumes the postgres container's name will be postgres, but in the compose file the postgres service does not have a container_name set, which will make the name dependent upon docker compose version. For me with the newest compose it is docker-postgres-1 where docker is the folder (stack) name, postrges is the service and it appends -1 because it is the first instance of this container. So I think container_name should be added to all the services in docker-compose.yml to simplify connection strings for this setup.

Browser

Browser independent

Steps to reproduce the behavior

1. Checkout master branch (2141774)
2. In deployment/docker follow steps from documentation
3. docker compose up -d
4. Check logs of backend container with docker logs -f (backend container name

Screenshots

No response

Additional context

No response

[Schwehn42]

Hi @Avalancs, thanks for taking the time to write up an issue. As for the first one, I'm glad you already found out yourself that commenting out the env vars does the trick, though I concede that it is kinda anti intuitive.

I've created issues for both points (#4661, #4662) and we'll hopefully get to them soon :)

[Avalancs]

Generally I would expect the application to check if Client ID and Client secret (or the other params) would be empty string and disable the feature or print a warning in the backend logs, that would make it easier to find the problem in the future :)

I might give these a go in the following weeks when I have some more time, thank you for creating the specific issues!