The idea is to have a similar feature to GH action cache where the user and action/tmt author are in charge of cache management. E.g. cache venv file with the key from pyproject.toml
Implementation: As a prepare/finish step plugin
This is the most straight-forward implementation
Pros:
More control on how it interacts with other prepare/finish steps
Cache keys can be dynamic, e.g. depending on some artifacts of the prepare step
Cons:
Harder to manage via CLI (may need the execution of previous prepare steps)
Implementation: As a dedicated phase
Could be a phase just after provision, but before prepare
Pros:
Easier to manage via CLI
Cache keys are available statically
Cons:
Cannot use any artifacts from prepare phase
Could interfere with multi-host setup
Provider's implementation
The provider could their own plugin to the cache plugin to provide their interface, e.g.:
Local provider
Under /var/tmp/tmt have a cache folder location with hashes of the cache key. Than mount/symlink the cache folder in the appropriate location, making sure it is read-only. Do the opposite if no cache key is found, and write a cache folder after the finish step
Other providers
Use the same principle for local provider, but before/after tmt execution load/save the cache, e.g. for github action load/save the cache. The issue is that the cache keys that need to be fetched must be made available before the tmt execution. So depending on the implementation used, this can either be queried via tmt cli, like a tmt plans show, or the provider would write a plugin such that these steps are executed within the tmt plan execution itself.
The idea is to have a similar feature to GH action cache where the user and action/tmt author are in charge of cache management. E.g. cache
venvfile with the key frompyproject.tomlImplementation: As a prepare/finish step plugin
This is the most straight-forward implementation
Pros:
Cons:
Implementation: As a dedicated phase
Could be a phase just after
provision, but beforepreparePros:
Cons:
Provider's implementation
The provider could their own plugin to the cache plugin to provide their interface, e.g.:
Local provider
Under
/var/tmp/tmthave acachefolder location with hashes of the cache key. Than mount/symlink the cache folder in the appropriate location, making sure it is read-only. Do the opposite if no cache key is found, and write a cache folder after the finish stepOther providers
Use the same principle for local provider, but before/after tmt execution load/save the cache, e.g. for github action load/save the cache. The issue is that the cache keys that need to be fetched must be made available before the tmt execution. So depending on the implementation used, this can either be queried via
tmtcli, like atmt plans show, or the provider would write a plugin such that these steps are executed within the tmt plan execution itself.