ci-images issueshttps://gitlab.haskell.org/ghc/ci-images/-/issues2019-09-16T21:56:46Zhttps://gitlab.haskell.org/ghc/ci-images/-/issues/1Docker-in-docker appears to be broken2019-09-16T21:56:46ZBen GamariDocker-in-docker appears to be brokenAt some point in the last few GitLab upgrades Docker-in-Docker builds broken, breaking CI here.At some point in the last few GitLab upgrades Docker-in-Docker builds broken, breaking CI here.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ci-images/-/issues/2Docker overlay2 backend is broken2019-09-17T16:03:40ZBen GamariDocker overlay2 backend is brokenDue to https://github.com/moby/moby/issues/39663. It has been disabled in `.gitlab-ci.yml` for now.Due to https://github.com/moby/moby/issues/39663. It has been disabled in `.gitlab-ci.yml` for now.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ci-images/-/issues/3Kaniko builds fail2021-06-16T19:00:13ZBen GamariKaniko builds failCurrently the build fails with:
```
Downloading artifacts for generate-dockerfiles (706425)...
Downloading artifacts from coordinator... ok id=706425 responseStatus=200 OK token=Z9kK2UKQ
Executing "step_script" stage of the job s...Currently the build fails with:
```
Downloading artifacts for generate-dockerfiles (706425)...
Downloading artifacts from coordinator... ok id=706425 responseStatus=200 OK token=Z9kK2UKQ
Executing "step_script" stage of the job script 00:01
Using docker image sha256:7053f62a27a84985c6ac886fcb5f9fa74090edb46536486f69364e3360f7c9ad for gcr.io/kaniko-project/executor:debug with digest gcr.io/kaniko-project/executor@sha256:fcccd2ab9f3892e33fc7f2e950c8e4fc665e7a4c66f6a9d70b300d7a2103592f ...
$ mkdir -p /kaniko/.docker
$ echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
$ /kaniko/executor \ # collapsed multi-line command
kaniko should only be run inside of a container, run with the --force flag if you are sure you want to continue
```
This appears to be an instance of https://github.com/GoogleContainerTools/kaniko/issues/1542https://gitlab.haskell.org/ghc/ci-images/-/issues/4Reduce image size2021-10-09T10:57:54ZJulian OspaldReduce image size## Motivation
1. improve download time in CI
2. improve disk use (images need to be unpacked after fetching)
3. improve download time for developers, when fetching images from gitlab registry to reproduce CI failures locally
## Suggest...## Motivation
1. improve download time in CI
2. improve disk use (images need to be unpacked after fetching)
3. improve download time for developers, when fetching images from gitlab registry to reproduce CI failures locally
## Suggestions
1. Merge layers (as few `RUN` instructions as possible)
2. omit installing multiple GHCs (e.g. many images install GHC both from repo and bindist... is there a reason?)
3. possibly delete `/opt/toolchain/store` after tool installation (is that safe for the binaries?)
## Example
1. `registry.gitlab.haskell.org/ghc/ci-images/x86_64-linux-alpine3_12:853f348f9caf38b08740b280296fbd34e09abb3a` has a compressed size of `1864.45 MB`
2. building the same image locally and pushing it to a local registry results in a compressed size of `1388 MB` (I don't know where the 500mb difference comes from... different compression algorithm?)
3. Merging layers and omitting extraneous repository-based GHC installation I could reduce the size to `869 MB`
See the manually modified [Dockerfile](https://github.com/hasufell/ci-images/blob/master/Dockerfile).
## TODO
* [ ] Test deletion of `/opt/toolchain/store`
* [ ] Provide a PR that fixes the Dhall configuration rather than the generated Dockerfileshttps://gitlab.haskell.org/ghc/ci-images/-/issues/5Images could be smaller2024-03-06T15:37:48ZBryan Rbryan@haskell.foundationImages could be smallerImages produced in this repo are large and could be smaller.
I looked into this when I noticed that downloading the CI image dominated runtime for Cabal jobs. A smaller image would make jobs faster and help with storage issues on runner...Images produced in this repo are large and could be smaller.
I looked into this when I noticed that downloading the CI image dominated runtime for Cabal jobs. A smaller image would make jobs faster and help with storage issues on runners.
I used `dive` to inspect the Docker image layers.
`dive registry.gitlab.haskell.org/ghc/ci-images/x86_64-linux-alpine3_15`
1. Total image size is 5.7GB
2. When unpacking GHC, /opt/ghc/9.4.3/lib[/share/doc] adds 600MB that I don't think are ever used
3. `cabal update` is run twice, once as `root` and once as `ghc`. Each run adds 1GB to the image. Presumably one of them could be avoided.
If we managed to drop 1.6 GB from this image, that would be a 28% savings.
I do wonder if it would be worthwhile to produce "slim" GHC bindists (or maybe just "official Docker images"?) that don't include docs. I imagine those 600 MB get passed around *a lot* in ephemeral CI jobs across the world.