#So how can people realistically use
1 messages ยท Page 1 of 1 (latest)
also found this, but its a much older message from @lethal plaza #1165204052154535956 message
There's also different strategies depending on how you're running GHA runners. If you have self-hosted runners (in k8s or otherwise) there are options. For managed runners, we had the experimental distributed cache which aimed to solve this. The issue to keep an eye on for a generalized solution is https://github.com/dagger/dagger/issues/8004
Some more context here @ashen ruin : #1306996556540543016 message
Thanks, I just read it all. This needs to be free, really, just like github and gitlab cache currently are.
Persist the Dagger volumes into a github cache at the end of the pipeline or something
If you find a way to reliably use Github's free caching service (hint: it's very unreliable, and they intentionally close access to the API to third party software), we will gladly merge it.
the dagger volume is already in the disk at /var/lib/dagger but this approach has several issues as it's not usually safe to share the same underlying dagger or docker volume across multiple builds
as it's not efficient (it uses a bunch of space) and data can become correputed quite easily
that's why you don't see any Docker docs suggesting to do the same in GHA
the reality is that there's no current silver bullet solution for ephemeral container caching. We had an attempt with our experimental distributed caching serivce and we're collecting that feedback to hopefully come back with a better solution ๐
So not docker caching but exporting the directory contents onto the github disk.
Then GHA cache of a .zip file
You don't need to bring docker into here.
So if the contents of that directory can be zipped up, then you can store a zip for next time, and then mount it in and unpack it .. on the next CI
Like ->export()
Without needing to call export()
@craggy crown
Hm this sounds a lot like https://github.com/dagger/dagger/pull/7646
As mentioned here, moving this from POC to fleshed out implementation ended up calling for a very different approach.
Will flesh out description more, but high level:
Needed to fork buildkit; corr...
Maybe not?
Creating zip exports of volume dirs
And then mounting and unpacking them ok the next run.
It would work. I think.
Has this been tried?
Kinda failing to remember all of the stuff around that, but skimming it seems like this was for a similar thing
Also why we worked with Depot.dev @ashen ruin
Is it free?
Same price as normal accelerated GHA from Depot
Okay, so it's going to cost teams $200/month to use Dagger + Depot (for caching). Got it ๐
What about open source projects who want to use Dagger, instead of GitHub or GitLab? Are we not targetting those projects? (their build times would be very very slow if they switched)
@lethal plaza why wouldn't this work?
Creating zip exports of volume dirs
And then mounting and unpacking them on the next run.
It would work. I think. Has this been tried?
Some people have small needs and spend zero, but there are lots of folks who spend many hundreds, thousands, and multiples of that on CI including GH Actions. Someone needs to pay for the compute. Many of our bigger users on GH employ self-hosted GH actions runners, often running on a manged Kubernetes like EKS. You better believe they get an AWS bill, but they can get a lot of caching from the cluster nodes through the basic /var/lib/dagger mechanism mentioned above.
Sure. I get that.
The little man just wants to bring Dagger into their company, from an OSS perspective, they probably have free github as well (it comes with github actions) .. so those people are no longer users anymore, since they can't cache anything .. build time will go up and Dagger won't get adopted by the team ..
Just one scenario that I foresee
This has been a hot topic for a while (plenty in Discord history), for sure, and one we'd love to see a solution for.
Creating zip exports of volume dirs
And then mounting and unpacking them on the next run.
It would work. I think. Has this been tried?
Poor mans caching. I think it would work. Why wouldn't it?
@ashen ruin this should/could work with the following caveats:
-
It's not currently possible to reliably export / import the cache volumes from the engine. As @craggy crown mentioned, more info about that here #1344341021055647845 message
-
Cache volumes are only a small part of the overall pipeline caching. Sure, they generally speed up the wall time of a pipeline but it really depends on what the pipeline is doing to get the most out of it. @upbeat plume kind of convinced me that an "ideal" world, cache volumes shouldn't exist as all the steps in a DAG should be content addressable, including pulling whatever asserts or artifacts that any vertex in the DAG needs.
So, to summarize, even if https://github.com/dagger/dagger/pull/7646 gets merged, it still won't be close to a "definitive" solution towards ephemeral runner caching
Hey @lethal plaza
We don't need any pipeline caching, just being able to export/import key things to/from the GHA cache.
For example node_modules, or the php_composer cache.
This stuff takes a lot of time, and team's won't bring Dagger OSS into the mix if they can't cache anything, without paying money to third party services.
What you need is for pipelines to not have "massive performance problems" as you said. Marcos is pointing out that there are different ways to do that, and which one is the most impactful is not always obvious or universally true in all pipelines.
(which is why we haven't solved it once and for all - yet!)
๐ I'm hijacking a bit this thread - we're on a different context, with self-hosted runner (using ARC). Is the approach described in this document still valid ?
https://dagger.io/blog/argo-cd-kubernetes
Are you aware of other infra setups solving the cache problem in the context of hosted GHA runners ?
yes, that approach is still valid @queen linden ! that's how the dagger/dagger pipelines are currently running. That same architecture
Oh, the joys!
โ ! fatal: unable to access 'https://github.com/levlaz/daggerverse/': Could not resolve host: github.com
I'm gonna re-install dagger, 15 minutes before the community call ๐
EDIT: Working nicely, found a few bugs in the Uninstall/Install docs.
Who can send me the github URL to work on the Install/Uninstall page?