[HN Gopher] Cicada - A FOSS, Cross-Platform Version of GitHub Ac...
___________________________________________________________________
Cicada - A FOSS, Cross-Platform Version of GitHub Actions and
Gitlab CI
Author : microflash
Score : 74 points
Date : 2023-11-06 15:36 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| danpalmer wrote:
| Having built CI/CD pipelines in CircleCI, Jenkins, GitLab CI,
| Concourse, Semaphore, and GitHub Actions, I'm not entirely sure
| what this offers, other than being FOSS. That's not to say that
| it being FOSS is not valuable - for some users it most certainly
| is - but that I can't see another way that this would be
| valuable.
|
| The config language is nice, but honestly I've never been
| bothered by YAML for pipelines. I want my pipelines to be
| declarative anyway. I'm a little disappointed that Cicada didn't
| go with one of the existing options such as Jsonnet, Cue, Dhall,
| etc.
|
| Lastly, there's a feature I've always found useful and in many
| cases necessary, that many CI systems don't have - enforced
| serial execution. When you're doing continuous delivery it's
| often critical to make sure that only one release is going out at
| a time and that the version being released strictly increases.
| I've seen outages because of release jobs racing and an
| unintended downgrade happening. This requires CI system support
| to achieve. Last time I checked, Jenkins, Concourse, and GitHub
| Actions all provided mechanisms for this, Semaphore may have as
| well. Circle and GitLab did not (the former after endless
| discussion with our account manager over it!) and I found it hard
| to trust the platforms as a result. Cicada does not appear to
| have this, which is a shame. It suggests to me a lack of hands-on
| production experience with continuous delivery. Arguably this is
| not a CD system, but there's no reason why a CI system shouldn't
| be CD as well, it's not until a much larger team/product size
| that a dedicated CD system becomes truly necessary and they take
| a lot of work to set up well.
| digi59404 wrote:
| Maybe I'm misunderstanding? For GitLab this should be doable by
| two different ways.
|
| The first is merge trains, which merges requests one by one to
| prevent this exact outcome. You just have to force all
| deployments to be done via a merge request. That's the
| downside.
|
| The second being forcing a GitLab Runner to run one job at a
| time. Tag it as "deployer" then ensure all deployment jobs are
| marked as "deployer". That runner will pick up deployment jobs
| one by one in order of first creation.
| danpalmer wrote:
| I think merge trains weren't a feature when I worked with
| GitLab, it was a while ago. This does certainly solve it, but
| at the cost of quite a different process. If what you're
| optimising for is time to release, merge trains add an
| overhead. At some point that overhead is worth it, but it
| depends on the team/product/etc.
|
| Having just one runner be the deployer is an option too. I
| think we used hosted runners so not sure if this is possible
| in that setup? This would also make pipelines harder to
| optimise. Often there are many parts in pipelines that are
| safe to do in parallel, and only a few "critical sections"
| around which you want locking. This would solve simultaneous
| releases, but not the general case of the problem (which at
| least Jenkins and GitHub Actions manage ok).
|
| GitLab always felt to me like Travis++, whereas systems
| developed later felt like they were built on fundamentally
| better primitives. Jenkins is a weird one because it has all
| of the features, can do all of these things, really quite
| well in many cases, but has a pretty bad developer experience
| and required a lot of maintenance to run a performant and
| secure install.
| tsak wrote:
| There's also a third way called resource groups [1]. We use
| that to ensure that we only run the newest job if we have
| multiple deployment jobs waiting for execution. This way even
| if we have multiple pipelines racing each other, only the
| last deployment job wins.
|
| [1] https://docs.gitlab.com/ee/ci/resource_groups/index.html
| skinner927 wrote:
| 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.
| snapplebobapple wrote:
| 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).
| spankalee wrote:
| This is very light on details. Does it actually allow you to run
| your GitHub Actions on your own servers?
| capableweb wrote:
| This is the syntax of the pipeline it seems:
| https://github.com/Cicada-Software/demo/blob/main/hello_worl...
|
| Short answer: No
| dboreham wrote:
| See comment above for how you can do that.
| barkingcat wrote:
| There is a collision in names:
|
| Cicada, this CI tool, uses a DSL (domain specific language) to
| write configuration, and this DSL is referred to as "Cicada
| language", and blasted in marketing copy as a "real programming
| language" on https://cicada.sh/ . The Cicada DSL is documented in
| https://cicada.sh/docs/ci-lang/index.html
|
| However, this is a completely different language from Cicada
| language, a programming language and theorem prover hosted at
| https://cicada-lang.org/ and https://github.com/cicada-
| lang/cicada .
|
| This name collision is very confusing, and I wonder why Cicada
| the CI tool didn't just stick to python, since it is also a "real
| programming language."
| bogwog wrote:
| I didn't know about that other Cicada language, but the part
| about using a DSL for this does seem unnecessary to me. I
| haven't dived into the docs at all, so if anyone has I'd be
| curious to know what this DSL offers over Python, Starlark, or
| any other existing programming language?
|
| Especially since, as far as I can tell, this is built on
| Python. So you already have a working Python installation at
| least.
| dbingham wrote:
| This is a misleading title. Being yet another CI tool is not the
| same thing as being a cross platform version of Github Actions
| and Gitlab CI.
|
| A cross platform version of Github Actions would allow you to run
| your actions using your own tooling.
| dboreham wrote:
| Also this exists:
|
| https://github.com/nektos/act
|
| which is conveniently packaged in a GH-a-like system by:
|
| https://gitea.com/gitea/act_runner
|
| in
|
| https://github.com/go-gitea
| debarshri wrote:
| Something I have noticed lately, First startup idea that every
| Devops person starts with is to create a CI/CD project because
| they think world is inefficient and workflows can be optimized,
| and then they pivot to other ideas.
| j45 wrote:
| So would that mean there is still room for improvement?
| leonheld wrote:
| What I really want is a 'Grand Translator' tool that allows any
| CI pipeline definition to be translated into any other CI
| pipeline definition.
|
| I want to take any .gitlab-ci.yml and magically translate it to a
| github workflow, and vice-versa. I know it isn't impossible, but
| it's a heck lot of work to get it right with all the hidden
| features behind declarative pipelines.
| ska wrote:
| If doing this sort of a migration is a real possibility, it's
| an argument for having the bare minimum logic in the CI tool
| and as much as you can in your own scripts...
| dindresto wrote:
| That's actually what we did for our monorepo. We had a huge
| Gitlab pipeline of multiple steps and jobs, now it's a single
| job pipeline that builds, tests and deploys 15 different
| projects, all powered by Nix and some Python scripts.
| sakopov wrote:
| We need a "terraform" for build pipelines.
| _joel wrote:
| oh god, please, no. :)
|
| I mean, go for it if you want but I'm not sure why you'd need
| to maintain so many heterogeous pipelines that would warrant
| a tool like this.
| endigma wrote:
| You should change your name. "Cicada" was also a CI/CD tool
| recently sunset by AWS after acquiring Fig. I maintain the
| community fork so I happen to know Amazon still holds a trademark
| on "Cicada"[1]. We rebranded to "Katoa" but you're going to run
| into them directly especially if you have any commercial plans.
|
| 1: Can't link, you can search "Cicada" and "Amazon" on the USPTO
| TESS
| biugbkifcjk wrote:
| I'm going to plug https://onedev.io/ its awesome. Its self hosted
| and has its own tooling for CI/CD. I feel it doesn't get enough
| love, but I've been using it for years for my own stuff.
___________________________________________________________________
(page generated 2023-11-06 21:00 UTC)