Cache VTK build in ASTE CI

[fsimonis]

Main changes of this PR

This PR uses the new ASTE CI image https://hub.docker.com/r/precice/ci-aste which is based on precice/precice:nightly and installs a working version of VTK from source.

https://github.com/precice/ci-images/blob/master/ci-aste.dockerfile

TODO

• keep or clean ci-image

Author's checklist

• I used the pre-commit hook and used pre-commit run --all to apply all available hooks.
• I added a test to cover the proposed changes in our test suite.
• I updated the documentation in docs/README.md.
• I added a changelog entry in ./changelog-entries/ (create if necessary).
• I updated potential breaking changes in the tutorial precice/tutorials/aste-turbine.

[davidscn]

I am not in favor of merging this change:

In the current CI, we simply build VTK inside the preCICE nightly image. This is at the moment only a temporary workaround for the broken ubuntu packages and will most likely be resolved with a future ubuntu version (24.10 is at least known to work).

Certainly, building VTK in each PR takes time (about 45mins or so). However, merging this or not is mostly a question of how much development is at the moment being pursued: with these changes, we would build VTK every day and push an image. New PRs are at the moment far below (maybe two per month).

Merging here is wasteful in my opinion. What we could consider is triggering an image update not every night, but by a PR or so.

[fsimonis]

Merging here is wasteful in my opinion. What we could consider is triggering an image update not every night, but by a PR or so.

It is wasteful for sure.

Given that the base image doesn't change, we could maybe get away with caching the installed VTK files using a long TTL. At best, this can be done whilst installing to /usr/local/. Otherwise, we may need to install to /opt.

[davidscn]

Given that the base image doesn't change, we could maybe get away with caching the installed VTK files using a long TTL. At best, this can be done whilst installing to /usr/local/. Otherwise, we may need to install to /opt.

I don't know how such a caching would look like. We could also store the VTK install in a separate image and the use docker compose. The result should be somewhat similar to a caching mechanism.

[fsimonis]

According to the GitHub docs

Workflow runs can restore caches created in either the current branch or the default branch (usually main).

Meaning we can keep a cache alive on develop and use it in PRs. I'll try this here

[davidscn]

I think that's now pretty much the ideal solution. If you push now a dummy commit, the VTK build show not be triggered, correct?

[fsimonis]

Triggered and reused the cache.

[fsimonis]

Ok I'll squash and merge this to make debugging the other PRs quicker.