Or just use Git LFS.

So the lockfile is a superset, but never a subset?

So it basically is an SBOM then but just sometimes has extra dependencies?

Superset of dependencies, but often a subset of info per depedency.

Ah okay! I know Rust has the transitive dependencies did not think/realise all languages might not, good point!

That is because GH Actions is event based, that is more powerful and flexible than just triggering on every push and not letting it be configured.

``` on: push ```

is the event trigger to act on every push.

You'll waste a lot of CI on building everything in my opinion, I only really care about the pull request.

> You can run all your CI locally

if you can, you don't need CI. we can't (too slow, needs an audit trail)

I think the idea is GitHub actions calls "build.sh", or "deploy.sh" etc. Those scripts contain all of the logic necessary to build or deploy or whatever. You can run those scripts locally for testing / development, or from CI for prod / auditing.

oh that makes sense. I thought the OP was suggesting running CI locally instead of a workflow on remote runners

Yes this is what I meant! If you structure it correctly using task runners and an environment manager you can do everything locally using the same versions etc. E.g.

```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

... ```

> My issue with Github CI is that it doesn't run your code in a container.

Is this not what you want?

https://docs.github.com/en/actions/how-tos/write-workflows/c...

> You just have github-runner-1 user and you need to manually check out repository, do your build and clean up after you're done with it. Very dirty and unpredictable. That's for self-hosted runner.

Yeah checking out everytime is a slight papercut I guess, but I guess it gives you control as sometimes you don't need to checkout anything or want a shallow/full clone. I guess if it checked out for you then their would be other papercuts.

I use their runners so never need to do any cleanup and get a fresh slate everytime.

In what way? I've never had an issue other than outages.

Code search over all of Gitlab (even if available) wouldn't help much when many of the interesting repos might be on Github. To be truly useful, it would need to index repos across many different forges. But there's a tension in presenting that to users if you're afraid that they might exit your ecosystem to go to another forge.

Surely you just need the workflow to not have embedded logic but call out to a task manager so you can do the same locally?

Well then why 99% of GH Actions functionality even exists.

It is fairly common pratice almost engineering best pratice to not put logic in CI. Just have it call out to a task runner, so you can run the same command locally for debugging etc. Think of CI more as a shell as a service, your just paying someone to enter some shell commands for you, you should be able to do exactly the same locally.

You can take this a setup furthur and use an environment manager to removing the installing of tools from CI as well for local/remote consistency and more benefits.

To lock you in.

Ergo, I'd rather use brainfuck to program CI.

What is wrong with GitHub Actions other than the outages? I've never hit a issue myself.

Geez, where to start.

I mean, … the outages are a big part of it. But those outages also extending to taking out my own hardware (e.g., through bugs like the above consuming resources on my own compute) is just double the pain.

But as a product, it's just bad? Riddled with bugs? In no particular order:

* Artifact APIs will return garbage results during a run. Note that the APIs are separate from the GHA actions for interacting with artifacts, and the latter uses undocumented APIs, presumably b/c the documented APIs are buggy AF.

* needs.… will just return junk data, if you typo.

* Builds of actions are not cached, making them rather slow. Many GH official actions hack around this by pointing the tag/branch (e.g., @v4) at a pre-built artifact.

* The pricing is high, compared to other offerings.

* The interface is just FUBAR: e.g., stdin is a pipe, which will wreak havoc on some commands that change their behavior when piped to. stdout & stderr are pipes, which although GHA ostensibly supports colored output, this basically renders it useless.

* Jobs, steps, actions are conceptual mud. There's a few ideas, like "execute this thing" in there, but its all jumbled up/duplicated. Container settings are configured per-job, so if you want to run some steps in one container, and some in another, but in the same job, you're just going to be left out to dry.

* Secrets are hard to manage, and even harder to not leak.

* The expression language has all sorts of corners, like coerced types and functions with parse-time side-effects!.

That's just a few of the bugs I've encountered.

> I mean, … the outages are a big part of it. But those outages also extending to taking out my own hardware (e.g., through bugs like the above consuming resources on my own compute) is just double the pain.

Never needed to run my own runner, but yes the outages are annoying.

> Artifact APIs will return garbage results during a run. Note that the APIs are separate from the GHA actions for interacting with artifacts, and the latter uses undocumented APIs, presumably b/c the documented APIs are buggy AF.

Never had an issue either I've only used the GitHub CLI to upload artifacts to releases.

> needs.… will just return junk data, if you typo.

Was not aware, but I have never typod. I'm wondering if a linter such as actionlint would catch this.

> Builds of actions are not cached, making them rather slow. Many GH official actions hack around this by pointing the tag/branch (e.g., @v4) at a pre-built artifact.

Is there not caching actions you can use?

> The pricing is high, compared to other offerings.

Try blacksmith.sh, half the price, faster and unlimited parallelisation etc.

> The interface is just FUBAR: e.g., stdin is a pipe, which will wreak havoc on some commands that change their behavior when piped to. stdout & stderr are pipes, which although GHA ostensibly supports colored output, this basically renders it useless.

I always call out to a task runner, I don't have command inside the workflow so never experienced this.

> Jobs, steps, actions are conceptual mud. There's a few ideas, like "execute this thing" in there, but its all jumbled up/duplicated.

Is it not each job has multiple steps, each step is an action?

> Container settings are configured per-job, so if you want to run some steps in one container, and some in another, but in the same job, you're just going to be left out to dry.

Yeah something you can't do, but never ran into this issue either. Ways around it, such as calling out to a script which does volume mounts and run things in a container using `docker run`. Or just cut up the problem so you don't need to and have multiple jobs or something.

> Secrets are hard to manage, and even harder to not leak.

For a personal account agreed, no way to set a secret for every repository. Recently I have been doing.

``` gh repo list --json name,owner --limit 100 | jq -r '.[] | "\(.owner.login)/\(.name)"' | while read repo; do if gh secret list --repo "${repo}" --json name | jq -e '.[] | select(.name=="EXAMPLE")' > /dev/null 2>&1; then gh secret set EXAMPLE --repo "${repo}" --body "${EXAMPLE}" fi done ```

> The expression language has all sorts of corners, like coerced types and functions with parse-time side-effects!.

Again I don't really have logic inside a workflow, I call out to Make or a script or something so it has never been an issue.

HN has no Markdown, but you can start each line with 2 spaces to format code:

https://news.ycombinator.com/formatdoc