Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using Radicle CI

radicle.xyz

Post reply on HN
Print view View original

41–49 of 49 posts

Re: Using Radicle CI

#41

Post by mdaniel »

cedws wrote: post #39
andrewaylett wrote: post #8

Earlier quoted context omitted.

Hear, hear. Although I'd slightly rephrase that to "if you don't change anything, you should end up running pretty much the same code locally as in CI". GitHub Actions is really annoying for this, as it has no supported local mode. Act is amazing, but insufficient: the default runner images are huge , so you can't use the same environment, and it's not supported. Pre-commit on the other hand is fantastic for this kin…

I have to disagree about Act, my experience is that it only works for extremely simple workflows, and even then it’s easy to run into differences between Act and GitHub Actions. I’ve raised many bugs but AFAIK there’s like one guy working on it in his own time. It’s terrible that the community has had to invent something like this when it should be provided by GitHub. I suspect the GitHub Actions team is a skeleton c…

> AFAIK there’s like one guy working on it in his own time

That may very well be true of nektos/act itself, but it now has at least two (depending on how one counts such things) ongoing forks over in the Gitea and Forgejo projects as they foolishly try to squat on it instead of using a real CI tool

Re: Using Radicle CI

#42

Post by cedws »

esafak wrote: post #40
cedws wrote: post #38

Earlier quoted context omitted.

I tried out Dagger hoping to tidy up some of our CI pipelines. I really wasn’t impressed to be honest. I initially just wanted to build a basic Docker image using BuildKit and even that was nightmare that the Dagger guys basically told me just isn’t supported.

When was this; dagger runs on top of buildkit?

Very recently. It may run on BuildKit but it doesn't expose it as a build runtime. IIRC Dagger implements its own way of building images that lacks BuildKit features and doesn't work with Dockerfiles.

Re: Using Radicle CI

#43

Post by lorenzleutgeb »

lbotos wrote: post #32

Op, Radicle had a very glitchy style home page before it went more 8-bit. Do you have an archive of that anywhere? I’d like to use it as reference for a style period in design!

Check the Wayback Machine. It has archived some of the previous iterations: https://web.archive.org/web/20250000000000*/radicle.xyz

Re: Using Radicle CI

#44

Post by shykes »

cedws wrote: post #42
esafak wrote: post #40

Earlier quoted context omitted.

When was this; dagger runs on top of buildkit?

Very recently. It may run on BuildKit but it doesn't expose it as a build runtime. IIRC Dagger implements its own way of building images that lacks BuildKit features and doesn't work with Dockerfiles.

Hello! I'm the co-founder of Dagger. It seems that there was a misunderstanding, sorry about that.

Dagger certainly can build a container image natively, without requiring a Dockerfile. It also can build a docker image from a Dockerfile, thanks to a built-in compatibility bridge.

Dagger doesn't expose a raw buildkit socket, but it exposes a cleaner API that has 99% feature parity. Hitting the remaining 1% is rare, but it does happen :) Is there a specific buildkit feature you were looking for? Perhaps we can add it.

Here's an example from the CLI (keeping in mind that there are SDKs for Go, Python, Typescript, PHP and Java with 1-1 feature parity to the CLI):

1. Natively (without Dockerfile):

  #!/usr/bin/env dagger
  
  container |
  from alpine |
  with-exec apk add golang |
  with-directory /src . |
  with-workdir /src |
  with-exec go build |
  publish myregistry.tld/myimage:mytag
2. Build a local directory with Dockerfile:

  #!/usr/bin/env dagger
  
  host |
  directory . |
  docker-build |
  publish myregistry.tld/myimage:mytag
3. Build straight from git remote, with Dockerfile:

  #!/usr/bin/env dagger
  
  git https://github.com/your/repo |
  branch main |
  tree |
  docker-build |
  publish myregistry.tld/myimage:mytag
I hope this helps! Sorry again that you got the wrong impression.

Re: Using Radicle CI

#45

Post by octopoc »

0x457 wrote: post #30
ambicapter wrote: post #14

Earlier quoted context omitted.

This is fine until your run into differences between your machine and the CI one (or you're writing code for a different architecture than the one you're using), but I agree, this is definitely the first step.

Plot twist, my build.sh invokes nix build and all I have to do on CI is to install nix and setup caching.

Double plot twist, I need to VPN into a remote network and now all the CI network activity goes through the VPN as well, and some of it gets blocked (true story)

Re: Using Radicle CI

#46

Post by cedws »

shykes wrote: post #44
cedws wrote: post #42

Earlier quoted context omitted.

Very recently. It may run on BuildKit but it doesn't expose it as a build runtime. IIRC Dagger implements its own way of building images that lacks BuildKit features and doesn't work with Dockerfiles.

Hello! I'm the co-founder of Dagger. It seems that there was a misunderstanding, sorry about that. Dagger certainly can build a container image natively, without requiring a Dockerfile. It also can build a docker image from a Dockerfile, thanks to a built-in compatibility bridge. Dagger doesn't expose a raw buildkit socket, but it exposes a cleaner API that has 99% feature parity. Hitting the remaining 1% is rare, bu…

Thanks for your reply. We use BuildKit's cache + SSH socket mounts in most of our Dockerfiles so this was a blocker I came up against immediately when trying Dagger. I'd rather not share my username here but there's a conversation on Discord last month you can dig up (search buildkit in:general) to see what was discussed and proposed solutions.

RE the part about not supporting Dockerfiles - sorry, that was incorrect, I misremembered.

Re: Using Radicle CI

#47

Post by shykes »

cedws wrote: post #46
shykes wrote: post #44

Earlier quoted context omitted.

Hello! I'm the co-founder of Dagger. It seems that there was a misunderstanding, sorry about that. Dagger certainly can build a container image natively, without requiring a Dockerfile. It also can build a docker image from a Dockerfile, thanks to a built-in compatibility bridge. Dagger doesn't expose a raw buildkit socket, but it exposes a cleaner API that has 99% feature parity. Hitting the remaining 1% is rare, bu…

Thanks for your reply. We use BuildKit's cache + SSH socket mounts in most of our Dockerfiles so this was a blocker I came up against immediately when trying Dagger. I'd rather not share my username here but there's a conversation on Discord last month you can dig up (search buildkit in:general) to see what was discussed and proposed solutions. RE the part about not supporting Dockerfiles - sorry, that was incorrect,…

Ah, I see the discussion thread on Discord, thanks.

It looks like you encountered a gap in the Dockerfile compatibility bridge, specifically lack of support for `--mount=type=ssh` [1]. It's true that our Dockerfile compat layer has more gaps than the native Dagger API itself. In effect, beyond very simple Dockerfiles, to get the full benefit of Dagger you need to convert them to code targeting the Dagger API. While there are many benefits to this, it does add significant friction to getting started.

It seems like we need to beef up our compatibility story!

Thanks for taking the time to share all this feedback, and sorry again that your experience didn't work out.

[1] https://github.com/dagger/dagger/issues/6736

Re: Using Radicle CI

#48

Post by __MatrixMan__ »

octopoc wrote: post #45
0x457 wrote: post #30

Earlier quoted context omitted.

Plot twist, my build.sh invokes nix build and all I have to do on CI is to install nix and setup caching.

Double plot twist, I need to VPN into a remote network and now all the CI network activity goes through the VPN as well, and some of it gets blocked (true story)

Your builds depend on the consistent behavior of remote servers? That sounds like a recipe for disaster.

Re: Using Radicle CI

#49

Post by andrewaylett »

cedws wrote: post #39
andrewaylett wrote: post #8

Earlier quoted context omitted.

Hear, hear. Although I'd slightly rephrase that to "if you don't change anything, you should end up running pretty much the same code locally as in CI". GitHub Actions is really annoying for this, as it has no supported local mode. Act is amazing, but insufficient: the default runner images are huge , so you can't use the same environment, and it's not supported. Pre-commit on the other hand is fantastic for this kin…

I have to disagree about Act, my experience is that it only works for extremely simple workflows, and even then it’s easy to run into differences between Act and GitHub Actions. I’ve raised many bugs but AFAIK there’s like one guy working on it in his own time. It’s terrible that the community has had to invent something like this when it should be provided by GitHub. I suspect the GitHub Actions team is a skeleton c…

I think we're in agreement, generally -- and GitHub have no incentive to help, because Actions are a moat and if it's too easy to run outside their environment then it's too easy to move away from their environment.

It's no shade on the author of Act (or on the quality of the code they've written) that they can't keep up with GitHub.

Post reply on HN