[Feature Request] Generate Workflow/Pipeline file(s) for CI/CD providers

[NatoNathan]

Katoa offers the ability to right CI/CD pipelines and scrips once and run them in multiple environments such as locally Remote Servers, and CI/CD providers such as GitHub Actions, Gitlab CI, Jenkins, and more.

A nice feature would be a feature that would help maintain portability, would be the Katoa CLI have a command to automatically generate the required files to run your Katoa pipelines and Jobs in common CI/CD environments.

Example Usage

katoa generate gh-actions # Generate GitHub Actions workflows for each Kotoa pipeline found in the repo

kotoa generate gitlab-ci <job> # Generate a gitlab ci pipeline for a single job

Ideally an alias like g or gen would be supported.

Possible Enhancements

A nice possibility would have an argument like --secrets-provider which could accept a secrets provider such as gh-actions (the default for GitHub actions workflows), 1Password, vault (by hashicorp) or others. This would then include the relevant configurational required in the workflows to load the secrets and make them available.

Another enhancement would be the ability to configure an environment for a job like

katoa gen gh-actions deploy --environment staging

[endigma]

Initial thoughts:

• I wonder if directly serializing some structs into YAML would be possible instead of templating it
• katoa already tracks some basic trigger info for pipelines as well so perhaps it could be expanded into a fat enum for different CI providers so the types make more sense.

[NatoNathan]

I wonder if directly serializing some structs into YAML would be possible instead of templating it

The issue there, is that some CI/CD systems use different languages and syntax like Jenkins uses a Jenkinsfile (Declarative Pipeline). You would probably need to write custom serializers.

That said only supporting generation to CI/CD systems that support a file format that already has a Serde serializer available is definitely an option, and support for other systems can be added once a Serde serializer is available.

[endigma]

"Custom serializer" is a road sign pointing directly at text templating, I suppose that's going to be more flexible anyway

Most templating engines are made for HTML, should look at the available crates and see what would be compatible with doing indentation sensitive YAML/etc instead

• https://crates.io/crates/tinytemplate
• https://crates.io/crates/handlebars
• https://crates.io/crates/tera
• https://crates.io/crates/askama

[NatoNathan]

Yeah, there’s definitely a trade off there, have a more “elegant and safe” solution by using struts and serializers but only can only support a subsets of CI/CD provides that use a a common syntax, or support as many providers and platforms as possible with templating with solutions that probably going to be more prone to bugs and harder to maintain.