Hacker News Reader

Comment by kureikain | Hacker News Reader

Github actions is nice but I think they go to wrong direction. The way they work is you are given an image then you have to use a thing call Github action, which basically just to extract out into YAML to define a certain steps for install any dependencies, execute shell script ...

I don't know why they didn't allow us to use any docker image we want so we don't have to waste time to use actions to install dependencies...Eg, if your app depend on both Go, Ruby, Node at build time you will need:

https://github.com/actions/setup-go https://github.com/actions/setup-node https://github.com/actions/setup-ruby

I much prefer CircleCI way

View on HN

If you want to run within a container so that you don't have to install dependencies, that's no problem. Just specify it as `jobs.<job-id>.container`. GitHub Actions will download and start that container, and any `run` commands that you specify within that job will run within that container.

Without that, they'll run directly on the virtual machine that you specify.

> Just specify it as `jobs.<job-id>.container`.

I don't know what this means. Are there any examples?

Running in a container is the one big thing I'm missing and couldn't find any documentation about.

Here's an example: https://www.edwardthomson.com/blog/github_actions_5_building...

I'm not sure if this is the 'right way' or not, but for a recent Go project, I just scripted the build via

    - name: build
      run: |
        docker run --rm -v \
          "$PWD":/usr/src/my-project \
          -w /usr/src/my-project \
          -e GOOS -e GOARCH \
          golang:1.13 go build -v -o my-project-$GOOS-$GOARCH
      env:
        GOOS: ${{ matrix.os }}
        GOARCH: ${{ matrix.arch }}

(GitHub Actions's build environment already has Docker installed/configured, so there's no setup necessary for "run: docker run" to work.)

I did this explicitly because I didn't want to use that "setup-go" action you linked, which at the time (I haven't doubled checked it recently) didn't support Go 1.13. Far better to me to use the Docker image, which has explicit instructions even for cross-platform compilation in its README, than rely on some weird action setup, in my opinion.

I like this approach as well, though I typically include a `Dockerfile` in my Go projects so my run task is just:

    - name: Build
      run: docker build -t me/image:latest .
      env:
        DOCKER_BUILDKIT: 1
        GOOS: ${{ matrix.os }}
        GOARCH: ${{ matrix.arch }}

Ah, well, the output of what I wrote above isn't actually a Docker image. It ends up writing a cross-compiled binary to the local FS, which I then later attach to a GitHub Release. (The goal was to automatically attach platform binaries to a release once it was made.)

...unless your Dockerfile ends up doing that too? If so I'd be interested to see it if you're willing to share!

You can use an arbitrary container: https://github.com/judge2020/test-actions2/blob/master/.gith... - https://github.com/judge2020/test-actions2/commit/5732cd3496... although I admit it's slower than CircleCI's runners.

My approach to this was to create generic images. For example there are various actions out there to "Run `make test`", "Run pytest", or "Run go tests".

Why be specific? Why not include a shell-script in your repository, and allow that to run the tests? That way you just need one "Run test-script" action:

https://github.com/skx/github-action-tester

I've done pretty much just this... choosing the appropriate OS image(s) and relying on a given scripting language in the environment.. the scripts themselves are in code and the YAML us just enough to run what's needed.

https://github.com/bbs-io/syncterm-windows/blob/master/.gith...

> I don't know why they didn't allow us to use any docker image we want

Can you imagine allowing anyone on the internet to run an arbitrary container on your server for free?

Many services already do allow this; including the aforementioned CircleCI

That is what every CI service in the world is. Docker doesn't intrinsically give you any privileges a shell script doesn't, but there is flexibility to really lock things down (like with gVisor). Of course, a lot of people run the Docker daemon in such a way as to give containers root access, which isn't ideal in a shared environment. There is no mandate to do such a thing, however.

I built an old-style Docker container (i.e., one that runs code like "apt-get install foo") on Github Actions successfully, so I assume Docker works fine. I haven't tried getting root on a build worker, but I imagine they mitigate that in some way. (Perhaps by having a pool of VMs and blowing it up after your build is done.)

I think what the OP is talking about is CI systems whose pipelines are declared by a series of "run this command in this container" instructions. Github Actions doesn't work that way, but you can still run containers.

Confirming that most other Ci services allow you to do that. I have done it in Gitlab for the Ci/CD of my Ionic apps.

We use Buddy: https://buddy.works/

Each step of a pipeline is just a docker container of your choice and running whatever commands you want with a persistent workspace volume throughout the pipeline.

There's a few others that work this way like Semaphore, Drone CI, GoCD, CircleCI, Azure Devops but none are as fast, seamless and easy as Buddy.

Your link blasts a song on click

It could be intentionally locked-in using the Action YAML. The proprietary nature could help with profits.

Reply on news.ycombinator.com