[Serow225]

Any chance of offering GitHub Runners as a tweak of the underlying “hard parts”? I’ve had really good luck with this type of offering from BuildJet, except that they don’t offer any ability to have persistent volume between runners. So all of our builds are fast _except_ the ones that build containers, but it’s too much of a pain to have some stuff in GitHub Actions with 3rd party hosted runner and then a totally different system for container builds/test workflows.

[jacobwg]

We actually briefly entertained the idea of adding GitHub Runners as well. :) Perhaps someday, but we have a long way to go just on just Docker / containers.

Just to note, you can totally use Depot within your GitHub Actions runs, even if those runs are happening inside self-hosted or BuildJet-hosted runners. You might get the best of both worlds that way, having your builds and tests outside of Docker run on BuildJet, and Docker builds accelerated with Depot.

[Serow225]

Thanks! Maybe it would be worth adding a docs example of a proper GH workflow using Depot?

It’s a decent option, but it’s still more complicated (multiple vendors, configuration, etc)

You know what, it could be really nice if y’all could create a simple Depot GH Action that would make things more efficient (for example pass in the repo token so that Depot could pull the repo vs first pulling it from GH into the workflow runner and then ship it over Depot)