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.

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?

@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!

@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.

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

I would love to see that feature! 

@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 }}

This is a great snippet! Thanks!

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

@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.

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

+1. Would really like to have this.

I ran into this while trying to run tests against Apache Solr, which supports configuration using custom entry points (https://solr.apache.org/guide/solr/latest/deployment-guide/solr-in-docker.html#custom-set-up-scripts) but not by, say, custom environmental variables or a well-known path which we could do with the current functionality.

@dakale for prioritization, I would note that this is an area where something which is very easy to do with GitLab CI is much harder to do with GitHub Actions. I use that all of the time at work so I was surprised not to have an equivalent here.

@chrispat ... it'd be nice to at least mention that it isn't supported in the docs. I ended up here after three hours of blindingly believing it was simple and I was just missing something obvious. I guess the good news is that I now have a way deeper understanding of GHA after that rabbit hole.

Ran into this with the same postgres fsync use-case here, being able to override the command'd be a good addition!