pine jackal
Hi,
In an scenario of ephemeral runners such as GH Actions, where the Dagger engine state is not persisted across multiple workflow executions, what are the options available, apart from:
a) Using Dagger Cloud.
b) Deploying the Dagger engine into a separate VM with a volume attached.
Otherwise, is _EXPERIMENTAL_DAGGER_CACHE_CONFIG: type=gha;mode=max a decent and recommended option?
full tusk
imho the dagger gha action should deal with cache so its done in the best way the team chose and also keep updated with latest recomendations. that said afaik there is no cache handling. did the EXPERIMENTAL flag works for you?
pine jackal
It didn't, the engine reported this error:
1: connect ERROR: cache config from env: cache config from env: missing type in cache config: "type=gha;mode=max"
hoary forge
It didn't, the engine reported this error:
```
1: connect ERROR: cache config f...
👋 IIRC in Dagger values are separated using commas instead of semi-colons. Ref; https://github.com/dagger/dagger/blob/cba51d5d014e5d34974c357e0016951cb1bf2fe8/core/integration/remotecache_test.go#L50
pine jackal
Thank you @hoary forge. Now I can see an error msg: 7: importing cache manifest from gha:8496054047234406796 ERROR: failed to configure gha cache importer: url not set for github actions cache. I think I also have to append ,url=$ACTIONS_CACHE_URL,token=$ACTIONS_RUNTIME_TOKEN
Hmm now it fails with ERROR: failed to configure gha cache importer: token contains an invalid number of segments 🤔
pine jackal
Ok apparently those 2 env vars are not exposed to the GH workflow by default, had to use: https://github.com/crazy-max/ghaction-github-runtime?tab=readme-ov-file#usage
Now I can see in the GHA workflow logs:
7: importing cache manifest from gha:8320202550342255111 DONE
7: importing cache manifest from gha:8320202550342255111 DONE
Although the cache is not working: the 1st run of the "go build" step took 58s, 2nd run took 60s 🫠
flint hound
Yeah the exporter combined with actions/checkout can be really tricky to get right, which is why we built dagger cloud. If you're on 0.10.3 you can use the new views feature to exclude as much as possible from the local dir when you pass it into the module. Worth noting as well that the gha exporter method does not support dagger's cache volumes, while dagger cloud does
full tusk
Yes but that will require been paying for both gha and dagger cloud
raw estuary
Am I wrong if I think dagger is very bad if you want cache without using dagger cloud? (I don't want to be dependent on dagger cloud), there is no solution for cache without dagger cloud, I am very disappointed.
hoary forge
@raw estuary it's the same situation as if you were running pure docker. There's no "recommended" way to cache Docker / Dagger builds in GHA because GHA doesn't offer the primites for it
that's why we had to develop our internal caching service to offer that capability
white sundial
I think in future you will purpose a feature where we can implement our custom storage fot that cache ?
hoary forge
Having said that, we're currently working on Storage Drivers (https://github.com/dagger/dagger/issues/8004) which will allow you to have more fine-grained control about your cache (like exporting it locally) so you can decide how to handle caching
raw estuary
I understand, but “scripted” CI solutions don't suffer from this problem.
this issue seems good
i'll be waiting, thank you for your work
hoary forge
I understand, but “scripted” CI solutions don't suffer from this problem.
if you use docker build in these "scripted" solutions, you'll have the same issue
so in summary, if your CI currently has to build an OCI image, you current don't have a straightforward caching answer because it's a complex issue.
white sundial
I think we want to cache vendor folder to PHP, node_modules to JS... And cache the first dagger init on gha that install go deps. So ability to cache volume...