| The parent comment was saying that those benefits could be applied to your build/CI scripts. Consider a complex (1000+ line) YAML GitHub action that involves building, testing, linting, deploying, releasing, etc. They are pretty common and are extremely hard to both read and write. Dagger fixes those issues for complex pipelines since you get to use a "real" language. > You mean "import functions into the CI code"? Why would I need that? It's usually possible through plugin systems, but I've never felt the need to put complex code into CI actions. This might just not be a use case for you, which is okay. This is just a general property of modern programming languages, and the result of Dagger being plain Go/TypeScript/etc. > Is that a test framework to test the CI code from within the CI? I hope I'll never want one! At AWS we could only deploy on certain days, e.g. we wanted to ensure that our pipelines didn't deploy to too many regions at once, that we didn't deploy during holidays, or during peak shopping times of the year. We had unit tests for our pipelines that ensured that the pipeline had the proper rules to enforce the above. I would imagine there are many other use cases for testing your pipeline. |
If one has a 1000+ yaml pipeline - this is not because they did not hear about dagger, but because they haven’t done proper decomposition and refactoring where all the complexity is abstracted away from pipelines dsl into proper general purposes language libraries