Run Docker build as part of CI checks

[mnonnenmacher]

To prevent that changes can break the Docker build unnoticed (like #1591 recently did), run the Docker build as part of the PR checks. This requires changing the Docker build workflow so that it can dry-run without pushing the images.

[Etsija]

BTW the local Compose environment is still broken with #1153 and we are required to manually keep our own version of docker-compose.yaml with

  keycloak:
    image: quay.io/keycloak/keycloak:24.0.5

I think the conclusion was to roll back #1153, but it eventually was not. Is there a particular reason for that?

[sschuberth]

Is there a particular reason for that?

Yes: No one filed a PR yet 😉

[Etsija]

Is there a particular reason for that?

Yes: No one filed a PR yet 😉

As I've not filed a "rollback" PR against the dependabot's PRs, is there a particular way to do it, or is it just a regular PR updating the keycloak version tag back to 24.0.5? I guess dependabot will eventually pick this up then and file another PR to try to update it back to 26.0.7?

[sschuberth]

is there a particular way to do it

You create a PR with a revert commit (created by git revert 16b90d79ac6d6e9586484d4a3767922e99ea1cca). In addition to the pre-populated commit message, you should shorten the mentioned commit SHA1 to 7 characters, and provide a rationale why the commit needs to be reverted. Then file a regular PR with this commit.

I guess dependabot will eventually pick this up then and file another PR to try to update it back to 26.0.7?

Yes, but this time we'll just close the PR unmerged, so that Renovate (it's not Dependabot) will remember to not propose that update again.

However, that's only a short-term solution until a new Keycloak 26.x version comes out, which will be proposed as an update by Renovate again, and there is a risk that it gets again accidentally merged. So obviously the better long-term solution is to fix the setup for Keycloak 26.x.

[mnonnenmacher]

Resolved by #1622.