* There is little to no inter-op between CI providers. Sure there are 3rd party providers, but they only seem to focus on the basics, like running a job when a commit is pushed. But, if you choose something like GitHub Actions, you are now locked into their platform, making switching Git hosting providers very painful.
* YAML. Everything is YAML. Sometimes it is just one big file (Gitlab, Travis, CircleCI, etc), and it becomes very hard to maintain very quickly. Workflows for GitHub Actions can be split up into different files, but at the end of the day, you are still writing YAML, which means no loops, conditionals, functions, and so forth. In addition, you must follow a strict file structure, meaning very little room for customization. In many cases, you need to write a Makefile/Python/shell script for more complex situations.
Does anyone else share these annoyances? Are there any similar sorts of issues that you deal with on a day to day basis that you wish could be improved?
If I were to build my own CI system, then it would have these features.
- Simple config format, ideally flat and not nested, so maybe toml.
- Ability to run any step, task, job, pipeline locally. It should be possible to do something like `ci run -t build` and have it execute the build task locally. This would greatly help with building CI pipelines and make it possible to just use the CI tool as the local build tool as well instead of having to essentially setup the same thing twice.
- Easy to self host, so not a million micro-services, but just one (or max 3) executable.
- Modular, it should be possible to extend it with plugins using webassembly or containers. Look at how Concourse CI does this for ideas.
Edit: I would pay for a license to something like that, maybe not a lot but I could justify up to $200 as a once off for a self-hosted solution like that if it's well made.
Btw. Gitlab allows splitting your pipelines to multiple files using include[1]. Also we have used gitlab-ci-local[2] to run our pipelines locally when developing them.
1: https://docs.gitlab.com/ee/ci/yaml/includes.html 2: https://github.com/firecow/gitlab-ci-local
Generally, I do as much as possible in the build system proper. The CI should mostly be running simple commands. Avoid GitHub Actions which can be trivially replaced with one or two shell commands (which is a lot of them).
Generally you want to aim for writing things in scripts that your CI system calls, so that they can be run locally trivially and so that migrating away from one CI provider (for whatever reason - cost, employer decides to shift, etc.) is not a huge piece of work.