How do I properly override a service entrypoint?

[carterbancroft]

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?

[weide-zhou]

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.

[carterbancroft]

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?

[dakale]

@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 

[carterbancroft]

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

[levrik]

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

[Ivaylo-Bachvarov]

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

I would love to see that feature! 

[bendavies]

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

[Ivaylo-Bachvarov]

This is a great snippet! Thanks!

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

[wojtekmach]

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

[genisd]

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

[gmile]

For what it's worth, I'm also facing inability to customize a command. For context, I'm now facing exactly the same issue with minio as @levrik had a few years back, as seen in this comment: https://github.com/orgs/community/discussions/26688#discussioncomment-3252879

[levrik]

We basically just switched to using a Docker Compose file instead since then 😕

[williamdes]

There is one very simple answer I found today in the replies of https://stackoverflow.com/a/64188150/5155484
Use minio/minio:edge-cicd ! (added by minio/minio#10933)

But it is not up to date so I did open a conversation here: minio/minio#16099

Here is how we do it

        services:
            s3:
                # See: https://stackoverflow.com/a/64188150/5155484
                image: minio/minio:edge-cicd
                options: --health-cmd "curl -s http://localhost:9000/minio/health/live"
                env:
                    MINIO_ROOT_USER: dev
                    MINIO_ROOT_PASSWORD: admindev
        steps:
            - name: Fetch mc client
              run: curl -o ./mc -# https://dl.min.io/client/mc/release/linux-amd64/mc && chmod +x ./mc
            - name: Create the dev bucket
              run: ./mc alias set minio http://s3:9000 dev admindev && ./mc mb minio/dev-bucket
            - name: Remove mc client
              run: rm -v ./mc
           # this also could work: docker run --rm --entrypoint /bin/sh minio/mc -exu -c 'mc alias set minio http://s3:9000 dev admindev;mc mb minio/dev-bucket;'
           # - [...] checkout and stuff

[joecotton-wk]

+1. Would really like to have this.

[acdha]

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.

[withinboredom]

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

[rohitpaulk]

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

[abe-winter]

linking back to the open PR for this feature in case it bumps it up the queue actions/runner#1152

implementing it is fairly simple (there's already an EntryPointArgs in the DockerCreate wrapper, it's just not populated from yaml)

[plutov]

Hey,

any update on this? Service containers are unusable to me as is without being able to override CMD.

[salvadoriume]

That is SO true! For me also. And solution for that (I don't know details) but seems easy win?