The docker/docker-compose-rest.yml file references the three backend images (ufal/dspace, ufal/dspace-postgres-pgcrypto, ufal/dspace-solr) via the rolling :dspace-7_x tag.
Downstream forks (such as ours) that build the frontend from source (e.g. after rebasing on clarin-v7) move forward with every frontend commit, while the backend only moves when docker compose pull is run explicitly, so the two can silently drift their version.
How I found out
I recently rebased our clarin.dk fork (currently running in preview while I migrate from our older DSoace install) onto the latest dspace-angular which is at 7.6.5, while the backend images stayed on a locally-cached 7.6.1 (which I didn't realise at first), so Shibboleth login broke because the 7.6.5 frontend calls /server/api/security/csrf (added in 7.6.5) and got 404. No error could be found in either container's logs, just a broken login flow.
Would it be possible to:
- Publish some kind of required version tag alongside each release (e.g. 7.6.5), or
- Pin docker-compose-rest.yml to such a tag, bumping it with each release? (I would definitely prefer this second option)
That makes the frontend/backend coupling explicit in the compose file and removes the chance of at last this particular issue occurring. Downstream repos such as ours can then rely on the upstream compose file as a source of truth instead of maintaining its own override.
The docker/docker-compose-rest.yml file references the three backend images (ufal/dspace, ufal/dspace-postgres-pgcrypto, ufal/dspace-solr) via the rolling :dspace-7_x tag.
Downstream forks (such as ours) that build the frontend from source (e.g. after rebasing on clarin-v7) move forward with every frontend commit, while the backend only moves when docker compose pull is run explicitly, so the two can silently drift their version.
How I found out
I recently rebased our clarin.dk fork (currently running in preview while I migrate from our older DSoace install) onto the latest dspace-angular which is at 7.6.5, while the backend images stayed on a locally-cached 7.6.1 (which I didn't realise at first), so Shibboleth login broke because the 7.6.5 frontend calls /server/api/security/csrf (added in 7.6.5) and got 404. No error could be found in either container's logs, just a broken login flow.
Would it be possible to:
That makes the frontend/backend coupling explicit in the compose file and removes the chance of at last this particular issue occurring. Downstream repos such as ours can then rely on the upstream compose file as a source of truth instead of maintaining its own override.