Creator of Cicada here. Thank you for the feedback! I've mentioned this in a few threads already, but the reason for making a new DSL for writing the workflows is that YAML makes it hard/cumbersome to express more complex workflows. Using a programming language though gives you more control over how your workflows execute. While there are already plenty of tools that use existing programming languages (ie, Python/TypeScript) to configure workflows, having a custom DSL allows you to make some of the more abstract terms like caching, conditional execution, permissions, etc. more explicit.
To your last point, I have experience with using CD in production, but not to the scale where I have builds stepping over each other and causing issues. I agree that serial builds are important in this case, and is something that I will need to look into (conceptually it sounds pretty simple).
You might want to check out the SparrowCI - it has combination of yaml AND standard programming languages ( Python/Ruby/GoLang/Powershell/Bash/Raku) giving you the best of two worlds - declarative style and extremely flexible flows when required
Awesome! I think serial builds should be fairly simple to implement if you can tie it back to a transaction in a data store.
I get the DSL desire, and I feel I've already lost the "YAML is fine" battle elsewhere so that's not a problem. I think a language like jsonnet or cue would have been a better choice simply because they don't involve users learning a new language or you from implementing a new language. Both would have allowed plugging in your own standard library of functions and abstractions.
Creator of Cicada here. I created a new DSL because I wanted a more declarative, expressive, yet capable file format, something like Dockerfile but with programming capabilities. In terms of "just running commands", Python (or any other language) is just as good if not better.
Where Cicada shines though is that it makes higher level concepts like conditional execution and caching front end center, so you can describe more with less lines. The DSL itself isn't very mature at the moment, but I plan on adding stuff like allow/deny capabilities and more in the future.
Creator of Cicada here. I mentioned this in another thread, but I have an experimental "GitHub Actions to Cicada" converter tool I'm working on that makes it easier to import GHA workflows to Cicada. GitHub already has an importer tool to import other git providers to GHA, but of course they don't have any export features.
Like you said, there are lots of intricate details you need to get right, and each CI/CD provider has a different ethos about how CI should be done. What I'm trying to do with Cicada is create one workflow format that gives you the power of GitHub Actions with their numerous event triggers, but make it work for other providers like Gitlab. Having one format that works with many providers is better than converting multiple formats back and forth, IMO.
Creator of Cicada here. Currently I am using GitHub SSO to reduce spam for the logins. When installing Cicada locally though you need to create an admin account, though there is no way (in the UI) to create new local users. Adding more sign-in methods (ie Gitlab, Bitbucket) is definitely on my radar.
Creator of Cicada here. Thank you for these questions! I'll try and answer them all:
0: Secrets are stored using Vault. Read this commit message [1] for a full breakdown.
1: Currently you cannot include other .ci files. I have been in feature creep mode for months now, and I've been forcing myself to stop adding features and start talking to users. The goal is to make Cicada more or less a general purpose programming language, but the first step is making it work well for defining CI/CD workflows.
2: If it is necessary, I could back-port the self-hosted runners to Python 3.10/3.9 or earlier. And, since the runner interface just uses websockets, I (or someone else) could make a runner in a different language, ie Rust or Go.
3: There is a "event" global variable that includes info like "event.branch", which is the branch that was pushed, but it does not include stuff like the default branch. Currently you could do `on git.push where event.branch is "main"`, but something like "event.branch is event.default_branch" would be even better. I'll work on adding that.
The value add currently is that Cicada is FOSS, platform agnostic (works with GitHub/Gitlab), and uses a language that consolidates the workflows and scripts into one manageable file format. Existing CI systems are already packed with features that people expect, so the current struggle is catching up to this and then adding more on top of that. I'm trying to focus on what sets Cicada apart: That it gives you more control over your workflows, while being expressive and easier to manage then YAML and shell scripts.
I definitely understand the reluctance towards feature creep, but I can imagine most bigger customers mightn't want to rewrite their include-heavy CI definitions in this, knowing it will come later and they'll have to rewrite again.
Thank you for the feedback. What in particular is making it hard to start trying it out? I'm curious because lowering the barrier for entry is important for getting people to start using this.
I havn't heard of any products or services that test the actual CI pipelines themselves, which seems like an interesting target market. I can't say how many times I have wanted to test out some CI workflow on some throw-away clone repo without mucking up the live repo.
It's good to know that you can use includes with Gitlab, And, from my quick glance at that second link, the setup process seems a bit involved. I don't like having to set up new user accounts just so that I can run a CI workflow locally.
I've been able to use the tool without setting up any accounts or other settings. Just run `gitlab-ci-local` in a folder where your `.gitlab-ci.yaml` lies.
I think these are all great points! I have came across Concourse CI, but have not looked too deeply into it yet.
I hadn't thought to use TOML for configuring CI pipelines, I'm curious what that might look like. TOML is indeed very flat, so it would be interesting to see what the equivalent TOML pipeline looks like compared to a YAML one.
I run Concourse CI for my personal stuff with the code in Fossil. It works decently enough, I like that it's somewhat extensible, but I have hit use cases that it can't really do like building an Alpine Linux cloud image.
As for YAML vs TOML, I am mostly sick of YAML, and I really like using TOML to configure Caddy, so I thought it might be good enough for CI config. I feel like it would be worth exploring, but maybe something slightly more complex or custom would be required.
To your last point, I have experience with using CD in production, but not to the scale where I have builds stepping over each other and causing issues. I agree that serial builds are important in this case, and is something that I will need to look into (conceptually it sounds pretty simple).