everything else is trash.
Github Actions changed the landscape.
They're composable.
The only two other things that come close is Concourse.CI and CircleCi.... and circle-ci is 100% trash
You can run all your CI locally if you don't embed your logic into the workflows, just use CI for orchestation. Use an env manager(Mise, Nix etc) to install tooling(you'll get consistency across your team & with CI) and call out to a task runner(scripts, Make, Task etc).
if you can, you don't need CI. we can't (too slow, needs an audit trail)
```yaml name: Continuous Integration (CI)
on: pull_request
permissions: contents: read
jobs: formatting: name: Formatting runs-on: ${{ matrix.architecture }} strategy: matrix: architecture: [ubuntu-24.04, ubuntu-24.04-arm] language: [rust, shell, python] steps: - name: Checkout code. uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1 - name: Setup Nix. uses: cachix/install-nix-action@4e002c8ec80594ecd40e759629461e26c8abed15 # v31.9.0 - name: Check formatting. run: nix develop -c make check-${{ matrix.language }}-formatting
linting:
name: Linting
runs-on: ${{ matrix.architecture }}
strategy:
matrix:
architecture: [ubuntu-24.04, ubuntu-24.04-arm]
language: [rust]
steps:
- name: Checkout code.
uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
- name: Setup Nix.
uses: cachix/install-nix-action@4e002c8ec80594ecd40e759629461e26c8abed15 # v31.9.0
- name: Check linting.
run: nix develop -c make check-${{ matrix.language }}-linting
compile:
name: Compile
runs-on: ${{ matrix.architecture }}
strategy:
matrix:
architecture: [ubuntu-24.04, ubuntu-24.04-arm]
steps:
- name: Checkout code.
uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
- name: Setup Nix.
uses: cachix/install-nix-action@4e002c8ec80594ecd40e759629461e26c8abed15 # v31.9.0
- name: Compile.
run: nix develop -c make compile
unit-test:
name: Unit Test
runs-on: ${{ matrix.architecture }}
strategy:
matrix:
architecture: [ubuntu-24.04, ubuntu-24.04-arm]
steps:
- name: Checkout code.
uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
- name: Setup Nix.
uses: cachix/install-nix-action@4e002c8ec80594ecd40e759629461e26c8abed15 # v31.9.0
- name: Unit test.
run: nix develop -c make unit-test
...
```If it works for you, great. But it is far from being good.
I've worked with Github Actions, Gitlab-CI and CircleCI in the last 10 years, and they've all been such an improvement over Jenkins, or god forbid, CVS with manual deployments, that I'm generally just counting my blessings.
For me the pain only came when not adhering to KISS. All the mentioned VCS are pretty much feature complete and only really differ on meta-topics (cost, license, lock-in) or niche topics (Actions marketplace, matrix builds, SSH on Runners). I've not yet run into an issue that would have actually blocked me, because there's always sh to fall back to in case of a bug or missing feature.
- everything else is trash.
- Github Actions changed the landscape.
- They're composable.
And I still hate github actions! Aside from anything else, they have one major flaw, which is there is no good development/test loop for writing them.
If you write most of your CICD in some kind of script, then you can run it locally, and do some basic checks around environment etc before deploying.
If you write most of your CICD in github actions or any alternative, you will be doomed to push 100 commits with messages like "maybe be?", "hmmm. . ." before eventually squashing them all down when it turns out several hours later that you mispelt an environment variable.
once you're done, make the actual changes in your real repo. I call the test repo 'pincushion'
We maintain an internal service that hosts two endpoints; /random-cat-picture (random >512KB image + UUID + text timestamp to evade caching) and /api/v1/generic.json which allows developers and platform folks to test out new ideas from commit to deploy behind a load balancer in an end-to-end fashion, it has saved countless headaches over the years.
The fact the business gives away free compute is irrelevant and more a discussion of their marketing budget.
Something like linked and dependent PRs in a chain would go someway to replicating Gerrit but again this basic functionality is not available out of the box for whatever reason.
i don't know why it's not more popular.
I grant you pipelines are the best bit about ado, but the fact that you can’t test them is a pain.
And the webhooks and templating are pretty messy and unpleasant quickly.
We’re changing from ADO to GitHub (had to be an MS product for corporate) and the infra people are looking forward to GHA as they prefer their maintenance to ADO pipelines.
What you can say for it, is that it was free and near infinitely hackable.
Please tell me how we somehow have been hobbled despite having simple and clear pipelines setup that autobuild any branch we want and allow one click deploys to our preprod environment and automatically manage versioning and scalably handle load from "Literally zero" to "Everyone in the company wants to rebuild everything now" and goes down less than github.
What are we supposedly missing?
More importantly, what are we missing that tangibly improves results for our consumers?
Multibranch is still weird and obviously added-on.
Writing plugins is ugly.
Oldschool maven type jobs where you type shell script into a `<textarea>`? Yeah, let's not talk about those, but we don't have a single one left anymore.
It's too powerful and there are too many of its implementation details exposed to the user.
The DSL semantics can be weird with when things like params/env expansions in options block are evaluated.
If someone is forcing you towards high stakes tight-coupling with no thought whatsoever towards the lock-in, you should get it in writing that "we at ${org} are fully committed to ${vendor} with ${platform}, on ${cloud} using ${tech} come what may, now and forever" and lots of sign off so that everyone knows who to blame when this is inevitably wrong.