The article gives a few examples of concrete things you can do:
- Build, run, and publish containers
- Containerize language-specific builds
- Run integration tests in ephemeral environments, in a repeatable way
- Run your tools in controlled sandboxes with only the files, secrets and network access they need
It also mentions what you might replace with it:
> When a workflow is too complex to fit in a regular shell, the next available option is often a brittle monolith: not as simple as a shell script, not as robust as full-blown software. The Dagger Shell aspires to help you replace that monolith with a collection of simple modules, composed with standard interfaces.
I already build containers with Docker. I already have Makefiles that build containers and run commands in them. I already replace my complex shell scripts with Python scripts.
How does Dagger help? I just can't get anything concrete from their site.
If you’re working on your own you may not need dagger.
If you’re working on a team often your shell scripts, python programs, and makes files are not always portable between local and CI, but even worse between your local machine and your colleagues local machine. This is where dagger shines because it lets you do all that stuff in a fully portable way.
I need an example to illustrate that, because I had to read this thread to even understand what I was reading/looking at.
A lot of projects and teams have been successfully using all tools mentioned in both CI and local dev envs. Portability and reusability of this “glue” stuff is a nice indicator of engineering maturity and culture within those projects and teams.
Low pro teams and individuals will happily abuse any new tool.
Mature teams stick to local-first CI - i.e. be able to run pipeline locally - and then translate to whatever is being used in their build and test infrastructure.