Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Corralling the proliferation of container images #7397

Open
chreekat opened this issue Apr 25, 2024 · 3 comments
Open

Corralling the proliferation of container images #7397

chreekat opened this issue Apr 25, 2024 · 3 comments

Comments

@chreekat
Copy link
Member

I've got a question about container images.

automated/build.sh runs most of its actions in an image ghcr.io/commercialhaskell/stackage/build . This image is built in a GitHub Action on the stackage repo. Its source is Dockerfile at the root of the stackage repo.

Separately, an image https://hub.docker.com/r/fpco/stack-build is built from within automated/build.sh itself. It's built from automated/dockerfiles/lts-*/Dockerfile .

Both images are tagged for particular LTSs, and both include all the system packages needed for building all of Stackage. The Dockerfiles RUN the same underlying scripts docker/*.sh .

I guess my first question is why are there two separate processes for creating similar-but-different images?

Second question - perhaps automated/dockerfiles/lts-22.7/Dockerfile should be setting the same STACK_VERSION as Dockerfile?

Third question: should we deprecate the Dockerhub images?

sorry for the issue title

@alaendle
Copy link
Member

Thanks for raising this issue @chreekat - it's always good when someone new looks at things - as @juhp already expressed on slack - we got used to these images 😄 .

To add my opinion: Long time ago I also relied on the fpco images (#5868) - so this was already an issue back in 2021. Also non of the images we provide is actual a good base for end-users to create their own haskell application images (also nowadays it is super easy to create a own tailored image by tools like ghcup). If the image is only used for some stackage related testing, the ghcr-image should be used - since this image at the end will get used during the builds. From my experience the published images make a promise that couldn't be kept (e.g. #6959 - and just take a look at docker hub how long this images is "only" a few 100 MB's in size and not the full 3-4 GB) - so I believe it's okay to deprecate.

@chreekat
Copy link
Member Author

chreekat commented Apr 29, 2024

Ok, let's deprecate https://hub.docker.com/r/fpco/stack-build and https://hub.docker.com/r/fpco/stack-build-small

  • Announce upcoming deprecation on Discourse, etc. to see if anyone can alert us to use cases we weren't aware of.
  • Find any docs mentioning the deprecated images and (???)
  • Update the overview blurb on the deprecated images to announce they are deprecated, also pointing to the new image
  • Remove the steps in stackage's build.sh that build and push the deprecated images

Edit: I originally wrote "find any docs mentioning the deprecated images and point them to https://github.com/commercialhaskell/stackage/pkgs/container/stackage%2Fbuild instead." But is that right?

@chreekat
Copy link
Member Author

I don't consider this high-priority so I won't be doing it myself any time soon 🙃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants