Build/push docker artifacts via GHA, with matching tags in GH and Docker Hub

[rufuspollock]

• making the ghcr.io package repository public (needs @datopian support)
• acquiring Docker login credentials to push to Docker Hub (or is there another docker hub we can push to?)
• ...

[rufuspollock]

@demenech any idea if we do have access to docker hub?

[demenech]

hi @rufuspollock

I have access. I'm working on adding deprecation warnings before pushing the latest version. Or would we want to keep docker hub support?

[demenech]

hello @rufuspollock

Merry Christimas.

I raised this PR with the deprecation warning and pushed 0.6.2 to dockerhub. I'll wait for some input before pushing to latest.

[athornton]

If we can get a DockerHub push token and you guys can stuff it into the organization-level secrets, we can reference it from GitHub Actions, and thereby push to both at the same time, but I and @vit-zikmund (and anyone else who isn't an org-level admin) won't be able to see the value. That might be the best thing overall?

[vit-zikmund]

Isn't this strange? All the time I thought we're seeking a different image hosting because it looked Datopian lost their keys from the dockerhub Datopian account. But then again, when @athornton jumped through all the hoops to get the ghcr.io push working, @demenech appears with the dockerhub keys! 🥇
Was keeping the secret away from us - Datopian little helpers - the problem all along? If so, and if what Adam writes is true, wouldn't it be simply better to keep just the old dockerhub?
This might be my resource-saving nature kicking in, but what is the reason to push to two registries? And eventually manage two image locations instead of one? I believe we should pick one and if it turns out it can be dockerhub, so be it, right?

[athornton]

Well, the reason we're moving away from Docker Hub at the Rubin Observatory is just that I've had a bad feeling about the viability of Docker-the-Company (note: NOT "docker" as a shorthand for OCI images and tools to do stuff with them, that's gonna be fine) for a while, and that feeling isn't getting better.

I am expecting Docker at some point (and I am surprised the point hasn't come yet) to get bought by someone like Oracle or Broadcom, who will pivot to squeezing their existing customers while putting the product on grudging minimalist life support, as companies like that do. And then the excessively generous free hosting they provide will go away.

Now, this is probably a worse concern for Rubin Observatory's science platform JupyterLab images with the analysis stack. That's because the image is now 12GB uncompressed, and we build a new one each night (I'm actually hoping to reap a bunch of those from our mirror at Google Artifact Registry today). For giftless, which is...not huge and not produced in many versions...it's not such a big deal, probably.

And, yeah, I'm keenly aware that GitHub is Microsoft, and as someone who lived through the 1990s as a Linux and OS/2 aficionado, trusting THEM seems sketchy too...but the whole Open Source world runs on GitHub and I think it would be harder for that particular incredibly-generous-free-hosting repository to go away. Hence ghcr.io.

Whatever we choose, though, I want builds, tags, and uploads to be driven by GitHub Actions, so there IS no manual release process beyond clicking "draft a new release" in the GitHub UI. It makes the process much much cleaner and more consistent compared to having to deal with it by hand.

If we can push to both until Docker Hub's demise as a free host (assuming I'm right about what happens to Docker-the-Company), I don't see why we shouldn't. But if I had to pick one or the other, I'd 100% pick GitHub.

[vit-zikmund]

Thanks for clarifying your reasoning there, @athornton. Much appreciated. I don't have any such strong feelings about it,, but that's likely just because I know very little about Docker-the-company. I won't stay in the way, as I really have no preference. What I want to ask, though, is how this fits in with the deprecation notice for dockerhub in #181. Idea of this issue feels like to be in a direct contrast with it. Because if we'll be pushing the same tags to dockerhub, doesn't it mean we'll want the images to be the same? And once dockerhub is in the CI loop, does it really make sense to deprecate it at the moment? I guess sure, we could do a dual automated build, one for GH and the other for dockerhub, but isn't that a bit too complicated? 🙂

[demenech]

hi @athornton

If we can get a DockerHub push token and you guys can stuff it into the organization-level secrets, we can reference it from GitHub Actions, and thereby push to both at the same time, but I and @vit-zikmund (and anyone else who isn't an org-level admin) won't be able to see the value. That might be the best thing overall?

This would be the best, but I think the main issue is in terms of the access control granularity - we cannot create access tokens that are restricted to a specific repository. I'll double-check with the other folks.

CC: @vit-zikmund

---

@anuveyatsu @rufuspollock do you have any thoughts on this?

[demenech]

@athornton @vit-zikmund I got permission to add the Dockerhub PAT to the secrets.

You should be able to use DOCKERHUB_LOGIN and DOCKERHUB_PAT on actions from now on.

EDIT: let me know if the names of the secrets should be something else

[athornton]

Cool. I won't have time to look at modifying the actions this week, but hopefully next week. If @vit-zikmund wants to tackle it I surely would not say no!

[vit-zikmund]

Sorry, I'm not a big friend with github actions nor have I ever setup pushing to dockerhub (should we automate pushing the readme too?). I haven't even found any github action code currently pushing to ghcr, so I suppose by the time I'd learn that reliably, @athornton will have his implementation done 🙈 (from which I can finally learn how to do it 😛)