feature-request

Support using worker nodes for docker builds

I have a docker builds which takes more than 10 minutes, and it times out on Depot. I'd prefer to use some of the compute I'm already paying for in my worker nodes for building, so I think it'd make sense to be able to select one of the clusters in the hub as a target for where the docker image will build. Also potentially moves some of the load off the built in cycle builder.

avatar
4
  • Hey Jeremy, thanks for that feature request.

    This is definitely something we've considered, to let users self host the factory service on their infrastructure.

    Thats pretty interesting that its timing out on Depot. Is the image really large or is it just dealing with big packages during certain stages that are later discarded?

    Does it time out using Cycle default factory service as well (the same way as Depot)?

    avatar
    platform
  • On reflection I was pretty tired at the time, and was struggling to get it to work (no fault of depot), and I knew my local docker builds were working so just gave up and ran it on my own infra which I knew worked (I'm still in PoC phase so if there's a bottleneck I'll need to work-around and come back to it).

    After checking the Depot logs, the actual issue that was the straw that broke the camels back was an out-of-memory exception during a Typescript build. On phone now but on my infra I have max old space bumped up, which might be carrying over to Docker, which might be why it worked. Easy fix I know 😅

    The thing that gave me the most grief and I struggled with for the longest time (which wouldn't be solved by running on my own infra when triggered by Cycle) was the paths in the config. My Docker file was configured to be run with the current working directory set to a sub-folder within the git repo(which then traverses up, sideways, and downwards to reference other dependencies). I did end up getting this working, took a bit of manipulation though, and I think the primary issue was that I didn't have a solid understanding of the full build process of the app and it's interaction with the Docker build (we currently don't use Docker in the build process, it's just a quick and dirty Docker file I set up ages ago that happens to work locally.)

    I'll give the Dockerfile a skim, make any modifications required, and give Depot a go, however the true impetus of the feature request was an emotional one -- and it drew me to the logical conclusion that it makes sense to be able to run the builds on our own infra using the baked-in Cycle trigger mechanism.

    Of course something very similar could already be achieved using Functions (and Pipelines), however doesn't feel quite first-class, only maybe 80-90%, and requires a little bit more work.

    Will report back with results of trying Depot again 👍

    avatar
  • Checking back in, after ensuring that the env is set correctly it does indeed build in Depot. Think the enhancement request still stands on it's own though :)

    avatar
  • Agree and its definitely on our radar, although not on the roadmap yet. I'm migrating these requests into our internal ticketing system so that they're tracked and when milestones are hit or they are released the appropriate folks are notified.

    avatar
    platform
v2024.08.14.01 © 2024 Petrichor Holdings, Inc.