Skip to content

Conversation

@larskanis
Copy link
Member

This is an addition to #170 . It rearranges the CI jobs so that common parts of the per platform Dockerfiles are built by a separate job and are re-used by subsequent depending docker build runs.

  • The advantage is that the same cache entries are used as the publish and release workflows.
  • The downside is that more CI jobs are used in cascade, slowing down the overall CI run.

@larskanis
Copy link
Member Author

In theory this should use less resources, because common parts of the Dockerfiles are only built once. But in reality the overhead of

  • setting up several subsequent VMs
  • setting up ruby and required gems
  • multiple implicit downloading of docker buildkit
  • and copying the build cache many times in and out

leads to slower CI runs. They grow from 7 minutes (all cached situation) to 11 minutes (all cached). Given that the complexity is also raised, I think it's better to keep the CI runs as they are.

The advantage is that the same cache entries are used as the publish and release workflows.
The downside is that more CI jobs are used in cascade, slowing down the overall CI run.
@larskanis larskanis force-pushed the size-on-push branch 2 times, most recently from 4d0d6a7 to c9d735a Compare November 1, 2025 03:02
The gha type is faster, but for some reason the gha cache type is not reliable.
It repeatedly has cache misses when there should be a cache hit.
The local storage cache in combination with achtions/cache doesn't show this behaviour.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants