lukadante3

Thank you for the encouraging words :) I typically do the same thing when there's only Helm chart available. There's also Kustomize plugin to inflate Helm charts . I'm still hesitant to use it though because I find it much easier to just maintain generated templates as a native kustomize since they're not a black box anymore.

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.

It's a pipeline engine for Kubernetes[1]. The idea is to build a tool that can be flexible enough for CI/CD, but also used for other things such as for example data processing.

The pipelines are just designed as serial and parallel execution of pods with no fancy features (i.e. loops or conditions) and the idea is to let other tools generate more complex pipelines using code.

Responsibility of triggering the pipelines is decoupled to standalone controllers such as github-screener[2] which enables triggering of pipelines used for CI/CD.

The project currently builds itself, but the docs are a bit outdated and there's quite a lot progress to be made.

[1] https://github.com/kuberik/engine

[2] https://github.com/kuberik/github-screener

[3] https://kuberik.io

Location: Switzerland

Remote: no

Willing to relocate: no

Technologies: kubernetes, go, Java. I'm interested in doing more Rust.

Resume: Via email

Email: luka.skugor@protonmail.com

I started as a full stack engineer after which I got interested in containerization, DevOps, CI/CD and then moved to site reliability engineering. I'm looking for an SRE position with focus on software engineering and a good balance between automating systems and coding.

Location: Zürich, Switzerland

Remote: no

Willing to relocate: no

Technologies: kubernetes, go, Java. I'm interested in doing more Rust.

Resume: Via email

Email: luka.skugor@protonmail.com

I started as a full stack engineer after which I got interested in CI/CD and then moved to site reliability engineering. I'm looking for an SRE/software position with a good balance between automating systems and coding.

Location: Zürich, Switzerland

Remote: no

Willing to relocate: no

Technologies: kubernetes, go, Java. I'm interested in doing more Rust.

Resume: Via email

Email: luka.skugor@protonmail.com

I started as a full stack engineer after which I got interested in CI/CD and then moved to site reliability engineering. I'm looking for an SRE/software position with a good balance between automating systems and coding.