#Struggling translating Dockerfile to dagger

1 messages · Page 1 of 1 (latest)

neon mural
#

I'm trying to use the new elixir (dagger_ex that uses the graphql) sdk to toy with dagger.

The 'getting started' examples I'm able to translate, but the phoenix generated Dockerfile (https://hexdocs.pm/phoenix/releases.html#containers) is a little more complicated.

I'm especially struggling with the COPY constructs and understanding (from the graphql documentation) what kind of parameters they take.

Would anyone have some examples (preferably in JS/TS) that are a little more complicated that might give me some pointers how to continue?

signal hazel
#

COPY is the equivalent of WithFile or WithDirectory dagger operations.

i.e:

# install mix dependencies
COPY mix.exs mix.lock ./
RUN mix deps.get --only $MIX_ENV

This would be equivalent to:

    const source = client.host().directory(".", { exclude: ["node_modules/"] })

    await client.container().from("node:16")
        .withFile("mix.exs", source.file("mix.exs"))
        .withFile("mix.lock", source.file("mix.lock"))
        .withExec(["sh", "-c", "mix deps.get --only $MIX_ENV"]).exitCode()
#

^ ofc you can refactor this to make it prettier by avoiding repetition in the withFile function.

neon mural
#

Awesome, thanks for the example. That made me able to translate it to the elixir sdk! I might get there 😄

#

Still a little confusing compared to Earthly (which I love due to the buildkit caching), but definitely worth to try it out. If I understood well the caching should be very similar due to the same buildkit 'behind the scenes'?

signal hazel
neon mural
#

My brain is having a little issue to what should be the expected result for something like running the typical apt-get update && apt-get install -y ... in combination with this caching as a first step in the build container

signal hazel
#

The main caching difference becomes when you need to run your pipelines in your CI runner environment. In Dagger we're building a very straightforward solution to make "universal cache" work anywhere in the most efficient way. If you're interested about that, you can send us a DM so we can tell you more about that

signal hazel
neon mural
#

Awesome, once I get it working locally I will! I'm running a self-hosted ci setup for this (forgejo + woodpecker ci, but it's (currently) just executing the Earthly step)

signal hazel
#

the cache acceleration private beta feature works best when you have ephemeral runners which don't have persistent cache.

neon mural
#

My setup is very simple, indeed just a single instance/host that runs the CI with dind (but I just pass the same docker socket, so it should work fine for the cache)

signal hazel
neon mural
#

Hmm, I'm getting close but still no success:

#

I first tried with push to a registry, but that didn't work either. Sadly I have no clue why

signal hazel
#

exporting and pushing is not working at all? Are those operations implemented in the elixir SDK? just checking...

#

or you're getting a different error?

neon mural
#

Just no output at all

#

I'd assume they are implemented, but I will double check that tomorrow

signal hazel
#

yeah.. seems like they're implemented indeed. I'll try to see if I have time in the weekend to help as well 🙏

signal hazel
#

cc @cerulean ivy

cerulean ivy
#

@neon mural Sorry for the delay. I've some fix on the gist you post here https://gist.github.com/wingyplus/ffa1f7b8f6a548715b9a11501f632c14. I use version dagger_ex 0.1.1 that requires to call id/1 for every resource you passing to. And fix it to make it work.

I tested it with regular phoenix project, not the umbrella apps. So it might be a bit difference than your setup.