With #9439 almost done, one of the next steps is #9444. To play with this, I created https://github.com/poikilotherm/test-image-push-flows, avoiding lots of noise in the main project and faster turn around times.
This actually works quite well already... See the packages at GHCR and at Docker Hub 1, Docker Hub 2
One of the crucial parts is to switch the Maven Unittest workflow to not run on push to any branch, but only for master and develop
This is a good idea anyway, as we avoid running the tests twice that way: once for the PR, once for the push
Just to clarify, we never push to master nor develop. These branches are protected. We do merge to them.
What I want to know:
@Philip Durbin @Guillermo Portas opinions plz?!
Oh and 3. do we need some kind of report comment what the name of the generated image is, so one does not need to dig through logs?
Philip Durbin said:
Just to clarify, we never push to master nor develop. These branches are protected. We do merge to them.
Absolutely - but when a PR is merged for these branches, this triggers a push event. So this is important to ship the stable/unstable images
@Philip Durbin @Guillermo Portas WDYT? https://github.com/poikilotherm/test-image-push-flows/pull/4#issuecomment-1470702800
I would remove PR images once PRs are closed or merged. I would update the develop and master tags once anything gets merged into them.
What he said. I agree. :happy:
What does it mean to remove a tag? Does that delete the image?
It should delete that particular version of the image and make it no more accesible for pulling
So the decision is that we are only going to use GitHub registry, not Docker Hub. Correct me if I am wrong please!
It sounds @Oliver Bertuch might have three open questions. Let's please take them one at a time. :happy:
Oh and by the way, @Oliver Bertuch I just tried to get this PR into the sprint (we were in a kickoff meeting) but we have other work to do. Sorry! :sweat_smile:
Philip Durbin said:
Oh and by the way, Oliver Bertuch I just tried to get this PR into the sprint (we were in a kickoff meeting) but we have other work to do. Sorry! :sweat_smile:
Meh. :melting_face: Containers still are not important.
Philip Durbin said:
What does it mean to remove a tag? Does that delete the image?
That kind of depends on the registry policies
Docker is much more strict with this than GHCR.
On the other hand, usually GHCR storage isn't free
It is free for public things on GHCR though
So maybe we could use sth. like https://github.com/marketplace/actions/container-retention-policy to cleanup once in a while
Delete old images. Sure. Makes sense.
So question 3 is already solved - I added an automated commenting already
Good! What's the next question?
What remains is question 1: be more strict with building?
Should we have some filter?
Filter can basically be anything
I mean maybe it's just fine to push images for all of it
What are the risks of simply pushing everything?
It would help with testing
As we don't pay a dime for our public images, I don't see much risk
Of course CPU cycles might be a thing
Maybe we can leave a comment in some code or in a doc that we can start filtering if need be and link to how.
RIght.
I think I'm quite fond of how this works now in the pet project
Looks like you're building an image with Java in it.
Yeah nothing fancy. Just some stupid stuff. Doesn't matter what is inside, the hard part was getting the flows right
Sure. Was there a last question? I've lost track. :sweat_smile: Thanks for hacking on all this! It's great! ![]()
I think I'm good
I wonder if I should put something into a Dataverse PR from this...
Given that even the most basic thing isn't even prioritized
Oh, we have a plan but you're not sure if it's worth coding it up? Because it isn't a priority?
Basically this stuff is done
It works as expected
Has all the features to make people happy
People can get going with this (at least for the application image)
Let's at least put an estimate on it, please.
Size: 3
Because I already did all the coding
And for testing it's better to use the pet project. Turnaround times in the main project are gonna be tremendously larger
I dunno if someone wants to write some docs how the pipeline works. Might be neat
Haha even the scheduled execution worked like a champ
https://github.com/poikilotherm/test-image-push-flows/actions/runs/4430739909
It build the base image anew, deployed it to Docker Hub and then rebuilt the app image on top of the new base
Thanks. I gave it a 3 and left a comment: https://github.com/IQSS/dataverse/pull/9447#issuecomment-1470812282
Thx. I added a comment about the pet project and the next step to get this into the PR
I think this is a better URL for the clean diff: https://github.com/IQSS/dataverse/compare/9434-app-container...9444-push-images . If you don't mind, I'll update the description. It's tiny! But this only pushes the base image, right? Not the app image.
Yeah, these were some initial fixes of stuff.
There's more in the pet project.
I probably shouldn't have done it in the pet project. I won't get as much commit counts now!
So... what does it take to move this PR from draft to ready? Start pushing the base image?
The base image will already be pushed. The addition in the PR was only about _scheduled_ pushes and a fix for getting a push to the stable tag when in main/master
Philip Durbin said:
So... what does it take to move this PR from draft to ready? Start pushing the base image?
https://github.com/IQSS/dataverse/pull/9447#issuecomment-1470815116 :see_no_evil:
Oh, I was clearly confused. This is about stable. Got it.
"ci(ct): fix pushing the correct tag (stable) for master branch" :-D
Ok, and copy workflows, add docs, etc. I think I get it.
The hard part is done.
Right. And the details are in the pet project.
-details +solutions
The details are the somewhat missing docs in a page in the guide
Ok. Still a 3. :happy:
So, with #9434 resolved, one next step is "do some push ups". (Pun intended)
I did give this a 3 and I just moved it to the top of the Dataverse Team column in the backlog.
Instead of "push images" can we give it a more specific title? "push dev app images to registries" maybe?
Morning @Philip Durbin - I am adding the necessary workflow scripts to push the images (so we can fulfill Milestone B). Would you be so kind to create two secrets in IQSS/dataverse for me? (GHCR_USERNAME & GHCR_TOKEN)
Thank you!
What should we put into the README for gdcc/dataverse that will be pushed to Docker Hub?
Suggestions welcome!
OK here's a draft. https://github.com/IQSS/dataverse/pull/9447/files#diff-774e1f5fbbba6ff5f99dbdc3457c545bb945a88402b69080516ecca7fcd4fdce
Looks good!
And I see the PR is no longer draft!
Yes it isn't. Might need polishing by review, otherwise probably good to go
And some front-end dev should test pulling from GHCR. Maybe @Guillermo Portas is up for it?
@Guillermo Portas was JUST talking about the need for a containerized dev env: https://github.com/IQSS/dataverse-frontend/issues/65
I suspect he'll be happy to see this pull request is no longer a draft! :happy:
There is a low volume but constant flow of output here
I would be glad to know if that crazy idea from my head is now actually of any use
Limited so far, of course. But a step in the hopefully right direction
I merged https://github.com/IQSS/dataverse/pull/9447
Now we have https://hub.docker.com/r/gdcc/dataverse
Thanks, @Oliver Bertuch ! ![]()
@Guillermo Portas check this out ^^
Awesome! I will be happy to test it when working in the development environment for frontend developers
Interesting first find already: the PR from ErykKul did not go through with pushing the PR Image because his workflow run does not have permission to access the credentials. Let's see if it works property for IQSS folks
This one was pushed: https://github.com/orgs/gdcc/packages/container/dataverse/88346793?tag=9361-storage-quotas
Via https://github.com/IQSS/dataverse/pull/9409#issuecomment-1522340389
Yes of course - that PR is based on a branch living at IQSS/dataverse and thus has access to the secrets. PRs with branches in forks don't have access to the secrets, so they won't be pushing images.
Probably the only way to resolve that is to push these images not to GDCC but IQSS as packages, because then the GITHUB_TOKEN should be enabled to write
Sounds fine to me. I'm not aware of any downsides.
I might have another idea. We could try using comments for these cases.
We can trigger actions on comments. So some core dev could trigger pushing the image by leaving a certain comment
This _should_ run the workflow with all the access to secrets...
Interesting. Sure, worth a shot.
I just added "push to registry" (this topic) to the agenda for tomorrow's meeting: https://docs.google.com/document/d/1Hz47lLjE9h1-YE5zD2wu4tT1ObB6vB6Nr3m16pQ4LF4/edit?usp=sharing
@Guillermo Portas I just added a parameter to set the tag in the command comment. It will still default to branch name, but you can override via named parameter. Here's the example: https://github.com/poikilotherm/test-image-push-flows/pull/8#issuecomment-1527054755
Note to self: make the job status visible by adding it as a check with https://github.com/marketplace/actions/github-checks
@Philip Durbin may I require your assistance this evening during tech hour?
Sure, what can I do for you?
Would you be so kind to create a fork of https://github.com/poikilotherm/test-image-push-flows, edit something so you can create a pull request this evening?
Just so we have a proper demo of what happens...
Whoops, I guess I missed this, sorry.
I just started a fresh topic for /push-images: https://dataverse.zulipchat.com/#narrow/stream/375812-containers/topic/.2Fpush-images
Oliver Bertuch has marked this topic as resolved.
Last updated: Oct 30 2025 at 05:14 UTC