Comment by msm_ | Hacker News Reader

Comment by msm_ | Hacker News Reader

Parent Full thread

This sounds fine and well, but it's not how Github Actions work (or at least, not the encouraged workflow). Let's have a look at the snippet from one of the projects I work on:

  - name: Set up Docker Buildx
    uses: docker/setup-buildx-action@v2
  - name: Build and push mwdb-core image
    uses: docker/build-push-action@v4
    with:
      file: ./deploy/docker/Dockerfile
      tags: |
        certpl/mwdb:${{ github.sha }}
        certpl/mwdb:master
      cache-from: |
        type=registry,ref=certpl/mwdb:buildcache
      outputs: type=docker,dest=./mwdb-image
  - name: Upload mwdb-core image
    uses: actions/upload-artifact@v3
    with:
      name: mwdb-image
      path: mwdb-image

Good luck running this locally. There's no script code to speak of, just references to external "actions" and parameters (for example, https://github.com/docker/setup-buildx-action).

Some CI platforms are just a simple glue layer (Gitlab CI - which I prefer - is one of them), but in most cases Github CI is not. Maybe it adds to the author frustration?

Building it that way is a choice. It's not mandatory.

You can use gitlab CI with special-purpose docker images for all your steps and magic parameters driving everything too (Gitlab AutoDevops works that way).

But if you just run your steps in shell scripts in vanilla docker images containing your build-time dependencies, you should be able to produce something that works the same in any CI pipeline, or locally.

The most annoying thing for me is that a lot of CI engines make docker-in-docker complicated. I love using compose to set up integration test environments, but doing that in CI is often a fight.

> Building it that way is a choice. It's not mandatory.

This ^ . In GitHub Actions, I personally try to use pre-baked actions as little as possible, for exactly the reasons I outlined.

I prefer GitLab CI, but you can make a mess of that just as easily. In general, if you approach CI as I suggested, you end up with something maintainable regardless of the CI engine in use.

Yeah, Github Actions has its cool parts, but I still prefer Gitlab CI since its just 'dumber', and doing custom things is simpler to achieve.

As another nod to GitLab's CI, it has sane autocomplete in the editor since the schema is mostly static. I'm not aware of any GitHub yaml tooling that downloads the descriptors(?) for any actions in use and with then allow autocomplete of its uses: or with: blocks

Reply on news.ycombinator.com