6 ms·

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, whic

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-go https://github.com/actions/setup-node https://github.com/actions/setup-node https://github.com/actions/setup-ruby https://github.com/actions/setup-ruby I much prefer CircleCI way

kwhat4 7y ago
> 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?
- pushpop 7y ago
  Many services already do allow this; including the aforementioned CircleCI
- jrockway 7y ago
  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.
- xtracto 7y ago
  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.
stevekemp 7y ago
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 https://github.com/skx/github-action-tester
- tracker1 7y ago
  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/.github/workflows/nightly.yml https://github.com/bbs-io/syncterm-windows/blob/master/.gith...
JMTQp8lwXL 7y ago
It could be intentionally locked-in using the Action YAML. The proprietary nature could help with profits.
manigandham 7y ago
We use Buddy: https://buddy.works/ 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.
- slow_donkey 7y ago
  Your link blasts a song on click
ReidZB 7y ago
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.
- tomphoolery 7y ago
  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 }}
  - ReidZB 7y ago
    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!
judge2020 7y ago
You can use an arbitrary container: https://github.com/judge2020/test-actions2/blob/master/.github/workflows/push.yml https://github.com/judge2020/test-actions2/blob/master/.gith... - https://github.com/judge2020/test-actions2/commit/5732cd349635c544f00143c306822c2e663692d7/checks?check_suite_id=367330126 https://github.com/judge2020/test-actions2/commit/5732cd3496... although I admit it's slower than CircleCI's runners.
ethomson 7y ago
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.
- jhasse 7y ago
  > 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.
  - ethomson 7y ago
    Here's an example: https://www.edwardthomson.com/blog/github_actions_5_building_in_containers.html https://www.edwardthomson.com/blog/github_actions_5_building...

kwhat4 7y ago

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

pushpop 7y ago
Many services already do allow this; including the aforementioned CircleCI
jrockway 7y ago
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.
xtracto 7y ago
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.

stevekemp 7y ago

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 https://github.com/skx/github-action-tester

tracker1 7y ago
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/.github/workflows/nightly.yml https://github.com/bbs-io/syncterm-windows/blob/master/.gith...

JMTQp8lwXL 7y ago

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

manigandham 7y ago

We use Buddy: https://buddy.works/ 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.

slow_donkey 7y ago
Your link blasts a song on click

ReidZB 7y ago

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.

tomphoolery 7y ago
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 }}
- ReidZB 7y ago
  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!

judge2020 7y ago

You can use an arbitrary container: https://github.com/judge2020/test-actions2/blob/master/.github/workflows/push.yml https://github.com/judge2020/test-actions2/blob/master/.gith... - https://github.com/judge2020/test-actions2/commit/5732cd349635c544f00143c306822c2e663692d7/checks?check_suite_id=367330126 https://github.com/judge2020/test-actions2/commit/5732cd3496... although I admit it's slower than CircleCI's runners.

ethomson 7y ago

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.

jhasse 7y ago
> 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.
- ethomson 7y ago
  Here's an example: https://www.edwardthomson.com/blog/github_actions_5_building_in_containers.html https://www.edwardthomson.com/blog/github_actions_5_building...