> Dev/CI drift: instead of writing the same automation twice - once in a CI-specific configuration, and again in a Docker compose file, shell script or Makefile - simply write a Dagger plan once, then run it in all environments.
Working on developer tooling, a lot of times I would hear from people that they wanted CI and dev to be 100% the same and wanted a simple "run all CI locally" command to pre-check before posting.
Unsure how Dagger is handling this but my concerns with the scenario I described
- CI normally divides things up into multiple jobs for speed which breaks the shared "do everything" command
- Commands need to scale down to fast iteration as people fix things
- Generally people get the best integration by using the underlying wrapped tools directly due to pre-commit or IDE integeration
> I would hear from people that they wanted CI and dev to be 100% the same and wanted a simple "run all CI locally" command to pre-check before posting.
This is exactly what developers should want. It's the most efficient workflow for a dev, because we then don't have to think at all. This is a huge dev efficiency anti-pattern: thinking your code is good to merge, pushing the change, and then finding out 10-20mins later that CI isn't happy for some reason that wasn't natural to check locally.
Working on developer tooling, a lot of times I would hear from people that they wanted CI and dev to be 100% the same and wanted a simple "run all CI locally" command to pre-check before posting.
Unsure how Dagger is handling this but my concerns with the scenario I described
- CI normally divides things up into multiple jobs for speed which breaks the shared "do everything" command
- Commands need to scale down to fast iteration as people fix things
- Generally people get the best integration by using the underlying wrapped tools directly due to pre-commit or IDE integeration