Comment by skinner927 | Hacker News Reader

Comment by skinner927 | Hacker News Reader

Parent Full thread

This project looks interesting, I very much like how secrets are handled, but here’s 3 reasons why, given what I can gather from the docs, I can’t use it right now.

1. It doesn’t seem it’s possible to include other .ci files? I have multiple projects that use the same ci config with their own augments and Cicada seemingly won’t work with that flow?

2. Self hosted non-docker runners are Python3.11. Some of us (albeit few of us) don’t have the luxury of being able to abandon ancient OS targets.

3. Doesn’t seem git.push allows branch to specified as “$DEFAULT_BRANCH” macro (or similar). Some projects use master, some use main, some use gold, whatever, it would be nice to not have to know.

The example CI repo is no more than a “hello world”. I don’t think people with simple CI requirements are interesting in switching from what they already have. Your target audience is likely someone like me who maintains 10k+ lines (merged) of GitLab YAML and wants to get out. I would be more encouraged to look deeper into this project if it could show me the value it adds, because right now it just seems like a different YAML that I’ll eventually loathe too.

Very neat project, I hope to see it mature.

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.

[1]: https://github.com/Cicada-Software/cicada/commit/2659f79b500...

> Currently you cannot include other .ci files

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.

It also seems to require github credentials instead of just supporting saml/ldap/local accounts and I don't see a way to make it work with over git providers (i.e. gitea) so not sure where the home gamer market would use this either? If I'm ponying up private github repositories already why wouldn't I just pony up slightly more to use their system? maybe I'm just missing it (I am, after all, a noob just scraping by on beginning to learn git and using it to manage a few things).

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.

Reply on news.ycombinator.com