How do I properly override a service entrypoint?

Code to Cloud GitHub Actions
#1

I want to define a service in my GitHub action and override its entrypoint by adding arguments to it. How can I do this? Here’s what I’ve got right now that should sum up what I want to do…

name: Node CI
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [12.x]

    services:
      etcd:
        image: microbox/etcd:2.1.1
        options: --entrypoint 'etcd --listen-client-urls http://0.0.0.0:2379 --advertise-client-urls http://0.0.0.0:2379'

    steps:
      ...

However, this blows up when initializing containers because the command it runs isn’t right…

/usr/bin/docker create --name 1062a703242743a29bbcfda9fc19c823_microboxetcd211_3767cc --label 488dfb --network github_network_244f1c7676b8488e99c66694d06a21f2 --network-alias etcd --entrypoint 'etcd --listen-client-urls http://0.0.0.0:2379 --advertise-client-urls http://0.0.0.0:2379' -e GITHUB_ACTIONS=true microbox/etcd:2.1.1

The error is:

unknown flag: --listen-client-urls

I think the generated create command should actually be something like this

/usr/bin/docker create --name 1062a703242743a29bbcfda9fc19c823_microboxetcd211_3767cc --label 488dfb --network github_network_244f1c7676b8488e99c66694d06a21f2 --network-alias etcd --entrypoint etcd -e GITHUB_ACTIONS=true microbox/etcd:2.1.1 --listen-client-urls http://0.0.0.0:2379 --advertise-client-urls http://0.0.0.0:2379

Here’s a docker-compose I’ve been using in Jenkins that I’m basing my action on:

version: '2'
  services:
    config:
      build: .
      links:
        - etcd

    etcd:
      image: microbox/etcd:2.1.1
      entrypoint: "etcd --listen-client-urls http://0.0.0.0:2379 --advertise-client-urls http://0.0.0.0:2379"
      hostname: etcd
      container_name: build_etcd
    expose:
      - 2379

Any ideas how within a GitHub Action Service definition I can override the entrypoint with arguments being passed to the executable?

6 Likes
#2

Hi @carterbancroft ,

The position of parameter ‘–listen-client-urls … --advertise-client-urls …’ will cause the error. now it invokes:

/usr/bin/docker create --name 1062a703242743a29bbcfda9fc19c823_microboxetcd211_3767cc --label 488dfb --network github_network_244f1c7676b8488e99c66694d06a21f2 --network-alias etcd --entrypoint 'etcd --listen-client-urls http://0.0.0.0:2379 --advertise-client-urls http://0.0.0.0:2379' -e GITHUB_ACTIONS=true microbox/etcd:2.1.1

It will be successful if you put them at the end of the code:

/usr/bin/docker create --name 1062a703242743a29bbcfda9fc19c823_microboxetcd211_3767cc --label 488dfb --network github_network_244f1c7676b8488e99c66694d06a21f2 --network-alias etcd --entrypoint etcd -e GITHUB_ACTIONS=true microbox/etcd:2.1.1 --listen-client-urls http://0.0.0.0:2379 --advertise-client-urls http://0.0.0.0:2379

It’s not supported to use these two parameters for services.options. Please remove them, it works fine on my side.

jobs:
  serviceimage:
    runs-on: [ubuntu-latest]
    strategy:
      matrix:
        node-version: [12.x]

    services:
      etcd:
        image: microbox/etcd:2.1.1
        options: --entrypoint etcd

Or instead of job.jobid.services, you can run the ‘docker create’ command directly in the job.steps.

#3

Hi @weide-zhou 

Thanks for the answer. That create command is generated on GitHub’s side, I don’t have power over where the params are placed. That’s what I was pointing out in my question, that those parameters need to go at the end of the command GitHub is generating.

The params are what I need so just doing options: --entrypoint etcd won’t work.

It sounds like you’re saying though, that for services in a workflow you cannot override the entrypoint with arguments. Is that right? It seems odd to be able to use services like that but not have an entrypoint option that works like it does in a docker-compose, generating the command properly.

Will this ever be supported?

#4

@chrispat This seems like a common ask, is it on the roadmap? I think we could support entrypoint+args on service containers similar to container actions

@carterbancroft You are correct that this is something we dont fully support at this time. Options was intended to allow arbitrary additional arguments but entrypoint is strange because of its positional requirements. While you can set the entrypoint alone, as you have noted you cant also provide the args to this entrypoint. At this time I think the only solution is to build the image yourself with the entrypoint + args defined in the Dockerfile 

7 Likes
#5

@dakalethanks for clarifying that, I really appreciate it. Your solution is basically what I wound up doing. Hopefully we’ll see this in a release at some point. Thanks again!

#6

@dakale I’m also currently hitting a similar issue with services in GitHub Actions.

I would like to set up a MinIO instance for some integration tests but the official Docker image requires you to specify the command yourself like server /data. It doesn’t start without this. Currently there seems to be no way of defining the command and/or arguments by yourself so I have to use a custom Docker image now.

1 Like
#7

My use case is to turn off the fsync to the postgress service for performance optimization.

I would love to see that feature! 

#8

@ivaylo-bachvarov  how about this:

services:
      postgres:
        image: postgres:12
        env:
          POSTGRES_DB: foo
          POSTGRES_USER: foo
          POSTGRES_PASSWORD: foo
        ports:
          - 5432:5432
        options: >-
          --mount type=tmpfs,destination=/var/lib/postgresql/data
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
    steps:
      - name: "Set some postgres settings"
        run: |
          docker exec ${{ job.services.postgres.id }} sh -c 'cat /var/lib/postgresql/data/postgresql.conf'
          docker exec ${{ job.services.postgres.id }} sh -c 'echo "fsync=off" >> /var/lib/postgresql/data/postgresql.conf'
          docker exec ${{ job.services.postgres.id }} sh -c 'echo "full_page_writes=off" >> /var/lib/postgresql/data/postgresql.conf'
          docker exec ${{ job.services.postgres.id }} sh -c 'echo "synchronous_commit=off" >> /var/lib/postgresql/data/postgresql.conf'
          docker kill --signal=SIGHUP ${{ job.services.postgres.id }}
3 Likes
#9

This is a great snippet! Thanks!

However I tested and it seems that my tests are slower now. That is strange :D 

#10

@dakale do you know if there are any plans to support this feature? Thanks for mentioning the workaround (building the image yourself with the correct args). I ended up calling docker run in my steps and then manually waited until the service is ready with until ...; do sleep 1; done. Using a service with args would definitely be more obvious and I could leverage service healthcheck which would be a big win too.

2 Likes
#12

Ping, this bad boy is 2 years old but I’d also like to have this feature :slight_smile:

1 Like