I'll think twice before using GitHub Actions again

So the way I've solved the multiple folders with independent checks is like this:

    all-done:
      name: All done
      # this is the job that should be marked as required on GitHub. It's the only one that'll reliably trigger
      # when any upstream fails: success
      # when all upstream skips: pass
      # when all upstream success: success
      # combination of upstream skip and success: success
      runs-on: ubuntu-latest
      needs:
        - calculate-version
        - cargo-build
        - cargo-fmt
        - cargo-clippy-and-report
        - cargo-test-and-report
        - docker-build
        - docker-publish
      if: |
        always()
      steps:
        - name: Fail!
          shell: bash
          if: |
            contains(needs.*.result, 'failure') ||
            contains(needs.*.result, 'cancelled')
          run: |
            echo "One / more upstream failed or was cancelled. Failing job..."
  
            exit 1
  
        - name: Success!
          shell: bash
          run: |
            echo "Great success!"

That way it is resilient against checks not running because they're not needed, but it still fails when any upstream actually fails.

Now, I did end up running the tests of the front-end and back-end because they upload coverage, and if my coverage tool doesn't get both, it'll consider it as a drop in coverage and fail its check.

But in general, I agree with the writer of the post that it all feels like it's not getting enough love.

For example, there is no support for yaml anchors, which really hampers reusability on things that cannot be extracted to separate flows (not to mention separate flows can only be nested 4 deep).

There is also the issue that any commit made by GitHub actions doesn't trigger another build. This is understandable, as you want to avoid endless builds, but sometimes it's needed, and then you need to do the ugly workaround with a PAT (and I believe it can't even be a fine-grained one). Combine that with policies that set a maximum time limit on tokens, your build becomes brittle, as now you need to chase down the person with admin access.

Then there is the issue of Docker actions. They tell you to pin the action to an sha to prevent replacements. Except the action itself points to a replaceable tag.

Lastly, there is a bug where when you create a report for your action, you cannot specify the parent it belongs to. So your ESLint report could be made a child of your coverage report.

It never becomes unbearably messy this way though.

The reason it gets unbearably messy is because most people google "how to do x in github actions" (e.g. send a slack message) and there is a way and it's almost always worse than scripting it yourself.

I’ll go so far as to say the massive add on/plugin list and featuritis of CI/CD tools is actively harmful to the sanity of your team.

The only functionality a CI tool should be providing is:

- starting and running an environment to build shit in

- accurately tracking success or failure

- accurate association of builds with artifacts

- telemetry (either their own or integration) and audit trails

- correlation with project planning software

- scheduled builds

- build chaining

That’s a lot, but it’s a lot less than any CI tool made in the last 15 years does, and that’s enough.

There’s a big difference for instance between having a tool that understands Maven information enough to present a build summary, and one with a Maven fetch/push task. The latter is a black box you can’t test locally, and your lead devs can’t either, so when it breaks, it triggers helplessness.

If the only answer to a build failure is to stare at config and wait for enlightenment, you fucked up.

Ah yes, I have a git alias created specifically for the "we don't know what it does until we push it" world of CI:

> yolo = "!git commit --all --amend --no-edit && git push --force #"

My recent experience with Github Actions is that it will randomly fail running a pipeline that hasn't changed with an incomprehensible error message. I re-run the action a few hours later and it works perfectly.