51–60 of 267 posts
Earlier quoted context omitted.
Dagger is already a popular dependency injection framework, so why choose a name that will be confusing to people who will likely use both of these frameworks in their projects?
These comments are extremely uninteresting. If you care so much, please just create an issue on their bugtracker or something.
Our team has had great success with GitHub Actions and Environments for CI/CD. One nice thing going that route is the build related code is contained within repositories. A large number of developers are already familiar wit GitHub, which makes onboarding new team members easier. I don’t see anything too compelling with dagger.io that is missing with GitHub. You can even use ACT to test workflow changes to builds loc…
I'm in the same boat, but I do think there's a prospect of Dagger being a superior option in the long term, if... 1. They invest in building out their catalog of actions to compete with GitHub's. I maintain a few GitHub Actions and despite the GitHub catalog's depth, it's still lacking in many ways and GitHub don't appear to invest in it too much: a "maintainer fund" and creative poaching from Dagger could rapidly br…
Earlier quoted context omitted.
I'm in the same boat, but I do think there's a prospect of Dagger being a superior option in the long term, if... 1. They invest in building out their catalog of actions to compete with GitHub's. I maintain a few GitHub Actions and despite the GitHub catalog's depth, it's still lacking in many ways and GitHub don't appear to invest in it too much: a "maintainer fund" and creative poaching from Dagger could rapidly br…
Also I'm sure he's on their radar given he works for Docker, but they should spend whatever it takes to hire github.com/crazy-max
> curl https://dl.dagger.io/dagger/install.ps1 -OutFile install.ps1
This uses the `curl` alias, which is really `Invoke-WebRequest`. It also makes the incorrect assumption I haven't fixed this dumb Microsoft mistake to be an alias to actual curl.exe.
> [Windows] We try to move the dagger binary under C:\Windows\System32
Ack, please don't do this! This is similar to installing something under /usr/sbin/. Malware is the only modern thing that would attempt to deploy to that folder.
> but in case we miss the necessary permissions, we'll save everything under /dagger > C:\\dagger.exe
I'm glad you have a non-admin fallback, but also: yuck. I don't want this polluting my home folder (more importantly: I don't want 100's of other things like this also polluting my home folder).
The "Windows way" is to install system-wide to %ProgramFiles%\dagger\ (eg c:\Program files\dagger\dagger.exe), or to install to %LocalAppData%\dagger\ (eg: c:\Users\shykes\AppData\Local\dagger\dagger.exe). The latter is kind of the closest equivalent to $HOME/.dagger on linux. Add whatever folder to the user's PATH environment variable to make it easy to run.
Honestly, providing just the .zip is better: then Windows users can muck up their own system however they like. Alternatively, package it with something like Scoop [2] which is a fairly popular dev tool, and provides a fairly easy way to get a sane install with updates, versioning and path stuff all handled.
One very important thing for my use case is being able to run steps in parallel distributed across multiple agents. Is it capable of this?
Your Windows instructions/process needs work. > curl https://dl.dagger.io/dagger/install.ps1 -OutFile install.ps1 This uses the `curl` alias, which is really `Invoke-WebRequest`. It also makes the incorrect assumption I haven't fixed this dumb Microsoft mistake to be an alias to actual curl.exe. > [Windows] We try to move the dagger binary under C:\Windows\System32 Ack, please don't do this! This is similar to instal…
Hi everyone, I'm one of the co-founders of Dagger (and before that founder of Docker). This is a big day for us, it's our first time sharing something new since, you know... Docker. If you have any questions, I'll be happy to answer them here!