My goal is try to make it simpler than other tools such as tekton by having less of its own DSL. For example, steps are mostly pure Job spec, instead of defining its own subset of features.
I think it's also more easily extensible than others if you want to trigger your pipeline in a different way. Sensors such as github-screener have a really simple event producing architecture.
One thing specific to github-screener is that it's focused on pull mechanism instead of relying on public webhooks like most of the other tools do. So you can easily host your private CI/CD without exposing a public endpoint.
(Edit) The reason I focused on having less of its own DSL because I ultimately saw how limiting it can be to have one. and it often end up as essentially a full featured language which is not reusable outside of the tool.
I think it's also more easily extensible than others if you want to trigger your pipeline in a different way. Sensors such as github-screener have a really simple event producing architecture.
One thing specific to github-screener is that it's focused on pull mechanism instead of relying on public webhooks like most of the other tools do. So you can easily host your private CI/CD without exposing a public endpoint.
(Edit) The reason I focused on having less of its own DSL because I ultimately saw how limiting it can be to have one. and it often end up as essentially a full featured language which is not reusable outside of the tool.