:wave:

👋

👋

Marcos from Uruguay here <3

👋

👋

Orbs are Kyle's favorite thing

"graphql-unstable" :eyes:

https://github.com/kpenfound/encircle

So, running CircleCI jobs on top of Dagger... amazing

Nice work, Kyle!

Q: is there a ceiling to compatibility? Could this in theory reach 100%?

lol

😆

Amazing

Very cool !

Kyle did you open the repo?

I did! Everyone should be able to see this now: https://github.com/kpenfound/encircle

Nice

GitHub 💀

Gaetan, any limitations in your current setup, problems that you'd like to see fixed in the future?

So you have 2 layers of local testing: first the dagger pipeline directly, then dagger+act to test that it will work in Github? Is that adding complexity to your workflow?

To make it even faster!!!

(sorry my mic isn't working well, thanks Miranda!)

👍

I'm just looking for ways to make your life even easier 😁

Relaying from @magocrysis: I wanted to relay that I've also noticed that running a go build via dagger is much slower.

"act" is a tool to run github actions workflows locally (in a best effort kind of way)

A tool for running GitHub workflows locally: https://github.com/nektos/act

magocrysis: Go build shouldn't be slower on Dagger... Can you reach out on discord or github? I'm sure we can help you fix the issue.

(my first guess is lack of persistence of cache volumes, which would cause the go cache to be empty each time)

I opened an issue to track slow go builds: if you're suffering from the issue, please send a little message there so we can get you sorted out! https://github.com/dagger/dagger/issues/4567

ka-ching

C__H__G :P

Is mounting docker socket in to the container a good practice from security perspective ?

You have to trust the things that have access to the socket.

While I tend to break steps apart in the CI pipeline for tracking duration, I’ve had great experience with the same approach of `mage init release:all slack:notify` for example.

Mounting the docker socket is a wonderfully useful escape hatch, that ideally you will never need in the future

+1 to Brian, I wouldn’t mount the docker socket to any workload you don’t trust… if you’re using dagger steps from open source make sure you trust them… also be careful about doing this on kubernetes (you shouldn’t mount your k8s host socket). that can cause a host of problems

Running a container on an external docker engine is strictly worse than running it on the dagger engine, but strictly better than not having any way to run it 🙂

(A bit late, but:) Go builds become MUCH faster once you use a cache volume for the Go build cache: https://github.com/dagger/dagger/pull/4543#discussion_r1100563584

Note that Dagger will soon have the ability to run services in containers directly, and setup container networking

https://github.com/dagger/dagger/pull/4505

Extensions remain super important, we just have limited engineering cycles

Nice. Will follow if I’m not already :-)

But we welcome contributions 🙂

https://github.com/gerhard/changelog.com/blob/track-commits-into-production/magefiles/legacy/legacy.go

BUT we are actually shipping some of the sub-components of extensions already

Newbie question: what is needed for that Fly.io setup? Just a "free" account of Fly.io?

so we are getting closer to shipping them

eg. services; dagger-in-dagger; hopefully entrypoints soon

https://github.com/dagger/registry-redirect/pull/1

Awesome, thx

Reminder here is Kyle's awesome circleCI compat project: https://github.com/kpenfound/encircle

https://discord.com/invite/dagger-io