GitHub action/docker image that doesn't change anymore

[set-soft]

The current v2/v2_d/v2_k6/v2_dk6 GitHub Actions and latest/ki6/dev/dev_k6 doesn't offer a frozen image/action. All of them has some degree of change. The v2/v2_k6 GitHub Actions and latest/ki6 changes with every release, and the others changes all the time.

Why not having a tag for each release?
Images weight over than 1 GiB (more than 400 MiB compressed) and they are stored at Docker Hub. We can't create tons of them.

This discussion is to talk about solutions and what people considers is best. The reason I started it is because @neilenns and @KyleHunter complained about glitches found in the images (mostly because they were unintentionally using development images, see #213 and #221).

To avoid these problems I switched v1 and v1_k6 to point to 10.4-5.1.9 and ki6.0.5_Debian, which won't change. I also created two new tags: v2_1_2_0 and v2_k6_1_2_0, both pointing to images that shouldn't change.

These tags will be stable, but won't get bugs fixed.

[neilenns]

Have you looked at storing images on GitHub instead? I gave up on Docker Hub when they claimed I was a business (I'm not) and refused to give me open source creator access. Not sure how much space/how many images GitHub allows though, but I am using it for some of my open source projects and it's working well for me.

Also what makes the images so big? Perhaps there are ways to trim them down?

[set-soft]

Hi @neilenns:

Never tried with GitHub. Do you know where to start learning about what they have?

About the size: KiCad is huge, it pulls a lot of stuff, and we aren't including the 3D libs, they are 5 GiB.

I use Docker Hub because the base images are already there (basically the Debian and Ubuntu official images)

[neilenns]

Here's their action documentation: https://docs.github.com/en/actions/publishing-packages/publishing-docker-images

Here's info on the container registry: https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry

Here's one of my repos that uses it: https://github.com/neilenns/ambientweather2mqtt and the action that runs to publish: https://github.com/neilenns/ambientweather2mqtt/blob/main/.github/workflows/release.yml

[neilenns]

Here's another repo I have that pushes to the container registry with a simpler build: https://github.com/neilenns/node-deepstackai-trigger/blob/main/.github/workflows/release.yml

[set-soft]

Thanks!
BTW: I found that the 950 MiB images (KiCad + Debian) can be compressed to 190 MiB using xz compression.
I'm uploading compressed back-ups of the old KiCad images to GitHub

[matthijskooijman]

Hm, just found this thread and wondering what this means for the specific version dev tags currently on the github docker repo. I'm using the dev_1.6.3-b1c268b_k7.0.2.1_d11.6_b3.4 in my workflow since I need some fixes not yet available in 1.6.2, but do not want to use dev (since that might break when changes to the dev branch are made later).

Can I expect that tag to stick around, or will it be cleaned up in the near future when development progresses?

[set-soft]

This tag will be cleaned. I only keep images for stable releases.
The dev images are kept for around 15 days, they live another 30 days if you use the hash, this is because GitHub doesn't really remove them when you ask to remove them. But a garbage collector (a workflow called clean) removes images periodically.
Why? The amount of resources used at GitHub is unknown, at least for the free version. I don't really know how much GB I'm using. The limit is also unknown. So I don't want to abuse.
Keeping all the dev images could waste a lot of resources. I don't know if GitHub has an optimized docker backend, but in my experience docker is quite dumb in terms of how docker layers are compressed and stored.
The current layers are quite optimized, it was really time consuming to create the current layout, but each new image takes some space.
I'll suggest using dev, as you already realized they aren't that unstable, only created after passing basic tests.