sunnyday_002's comments

Or just use Git LFS.

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

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

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

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

... ```

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.

Pin the action's version via a digest and use Renovate for updates.

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).

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

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.

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

One of my favourite GitHub features is the ability to do a code search over the whole of GitHub, not sure GitLab has the same when I use to use it?

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?

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