I just made this PR and I'd love to discuss it: support SPA dev - #12746
At the moment, in that PR, we have two Keycloak realms. We should get it back down to one, right?
Trying to get us back down to one in https://github.com/IQSS/dataverse/pull/12746/changes/465f12dfaf757cb32a761f0d7faff346d6ecc967
At tech hours just gave a demo of spinning up the backend and then the frontend along side it (just the frontend, no containers). It worked!
@Oliver Bertuch sorry you missed it. Any objection to me merging #12746? I begged someone, anyone, to approve it (still waiting). :sweat_smile:
"failed to push quay.io/gdcc/configbaker 401 UNAUTHORIZED" seen at https://github.com/IQSS/dataverse/actions/runs/36610067205/job/109552748623?pr=12746
@Oliver Bertuch any ideas on this one? :thinking:
I suspect a bug (feature?) in the DMP, causing the quay.io registry name to bleed from the Keycloak build into the Maven properties. It's the only way why all of a sudden Maven's docker.registry would be set to quay.io, as the Dockerfile and compose file in conf/keycloak are the only relevant places in all of our codebase where quay.io appears (aside from docs and a JUnit test).
Huh, so probably unrelated to that PR? (For discussion of that PR, please see #containers > support SPA dev #12746.)
Not unrelated. You are adding a build section for Keycloak to docker-compose-dev!
Oh! :sweat_smile:
Since it's related, I combined the topics.
@Oliver Bertuch I listened to the 2023-04-27 container meeting (notes) and it gave me some perspective on where we were back then.
Back then I was the only one using the backend Docker dev env and I had only been using it for a month.
Also, a couple times we said that we really want a simple solution for frontend developers who don't even have Java installed.
Not once did I say, "Wait! Frontend developers should just run the backend the same way the backend developers do!" Guillermo said, "I'm gonna go build the dev-env stuff in the frontend repo to spin up containers over there." And I didn't stop him. I was like go go go, do it!
So nice that we have these recordings!
yeah
It's pretty different now. Cheng and JP are both quite comfortable hacking on Java.
Nice. So there's been a transition. Sound like it's about time to change the flow.
Yeah. I mean, the dev-env will still work. We'll see what the pain points are when trying to switch away.
I mentioned how the frontend only supports S3.
Maybe we'll want to switch the backend dev env to use S3 by default?!?
These things are really hard IMO. We are asking devs to take a toll when we keep adding stuff. With hardware being at a premium, it makes we worried we are raising entry barriers.
I'm wondering if we can make use of something like profiles.
So devs can activate things as needed
sure
We tried to help Parth karalkar but his laptop was underpowered. More recently Janvi Kapoor had the same problem.
And this is not going to change any time soon I'm afraid ![]()
![]()
Compose has profiles: https://docs.docker.com/compose/how-tos/profiles/
nice
But we might need to add this to DMP
There probably is no support for this.
I don't know if we should move away from DMP
You keep saying that. :smile:
I still like how integrated it is and how clean we can generate our images
But maybe we need to stop trying to work against the ecosystem's flow.
if it's not fun, why do it? :smile:
We should probably try to talk with our fellow devs who use containers what they want
If people feel more comfortable using Maven for everything, it may be worth it.
I did all the Maven things to optimize Docker layers and make it more accessible. But if people don't care about that... ![]()
Right now, the container workflow for local development, testing, and even the GitHub workflows in the develop branch (JSF and integration tests) is just mvn -Pct package and mvn -Pct docker:start. This is highly convenient, super fast, and deeply integrated. I would really hate to see it go away from a workflow perspective.
Thanks for sharing your perspective!
I use mvn -Pct exclusively (rather than docker compose). Works fine. No complaints.
After going through the manual install process, my respect for this workflow has become 100x
Uh oh. As of https://github.com/IQSS/dataverse/pull/12746/changes/dffc9366ee853a14d685994188b86514138b5afd (where I tried to switch to DMP for building Keycloak) I'm now seeing this:
[ERROR] DOCKER> Unable to build image [gdcc/keycloak:unstable] : "ADD failed: failed to GET https://repo1.maven.org/maven2/com/oracle/database/jdbc/ojdbc11/23.8.0.25.04/ojdbc11-23.8.0.25.04.jar with status 429 Too Many Requests: This tool has been identified as abusive and/or wasteful in the way it interacts with Maven Central. Use a caching proxy to limit your impact on the ecosystem. https://www.linkedin.com/feed/update/urn:li:activity:7456004385634992128/"
From https://github.com/IQSS/dataverse/actions/runs/36633121641/job/109630839749?pr=12746
Yeah - this is probably due to Maven downloading the internet all the time
Oh. I assumed I did something wrong in that commit. Which I probably did, who knows.
I changed a few more files than we talked about.
At the moment, we only need the Keycloak image locally in development. Can we prevent it from being built and pushed in CI? :thinking:
@Oliver Bertuch I deleted that commit (preserved it, first) and replaced it with this approach of not building or pushing the dev_keycloak image: https://github.com/IQSS/dataverse/pull/12746/changes/f8786261fd16a2b6a4f6a038cdf5ecdb247a9b69
Sounds good!
I suspect the Keycloak stuff should be moved to either its own repo or at least Maven module...
It would be so much easier if we'd have a proper Maven module structure in our repo... :see_no_evil:
Yes, we do have #12597 about moving the jar to its own repo.
Hmm, CI is failing with "Unable to pull 'gdcc/keycloak:latest'". I shouldn't be surprised, I guess.
Maybe this wasn't such a hot idea. :thinking: I preserved the commit above.
A variation on the approach above. Whitelisting images to build and push in order to exclude dev_keycloak from being built and pushed: https://github.com/IQSS/dataverse/pull/12746/changes/900fed0f8c194284a80065c427261b639597d520
tests are passing!
@Oliver Bertuch what do you think?!? :sweat_smile:
This existing comment is confusing now, given what I added...
"Build the application image, but skip the configbaker image (that's a different job)!"
... because I'm whitelisting the configbaker image (and the app image). :thinking:
All I know is tests are passing and I have the SPA running! ![]()
Not to give you some murky mojo, but did you try adding a skip config for the keycloak image and maybe set that to true by default?
The filter works, sure, but there may be unintended side effects now.
No, I didn't try a skip config.
@Oliver Bertuch do you want me to try something? I'm a little fuzzy on what you want. Please feel free to bang on the branch!
I don't want anything. Just not sure what the best approach is. But hey, we can always circle back and do multiple steps. At the time the keycloak stuff gets thrown out, we just need to remember to get this stuff out again. Maybe leave a comment on the CI workflows with a cross ref to #12597?
Sure, I'll do that.
What about the existing comment I mentioned above?
The comment says we are skipping configbaker, but the filter I added is saying to include configbaker. :thinking: Who's right? Should I remove configbaker from the filter? :thinking:
Oh. Ehem. Not sure? :see_no_evil:
Well, maybe we can talk it out more at the container meeting tomorrow.
My goal is to get it merged so I can have the SPA running all the time. Happy to do whatever to get it approved! :smile:
I'll bark like a dog. ![]()
I'll cluck like a chicken. :chicken:
![]()
Last updated: Oct 02 2026 at 18:51 UTC