Service container command arguments

[tylde]

Hey, I haven't found any suitable solution for passing arguments to service container.
For example I would like to use trufflesuite/ganache:latest image as job's service container with --wallet.deterministic option.

Unfortunately there is no such thing as jobs.<job_id>.services.<service_id>.command option to achieve that:

# workflow.yml
jobs:
  job:
    services:
      ganache:
        image: trufflesuite/ganache:latest
        ports:
          - 8545:8545
     steps:
     # ...

In docker-compose.yml file I can use command to pass arguments:

  # docker-compose.yml
  ganache:
    image: trufflesuite/ganache:latest
    ports:
      - 8545:8545
    command:
      --wallet.deterministic

Are you planning to add this feature?

[TroyKomodo]

I am confused how this feature was not implemented on release.
It might just be most common thing to do. Kinda 🤯

[tiagoliveira9]

True, it doesn't make sense.

[jaeyson]

It's already 2 years and I still can't see the command in workflow syntax docs :(

[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)

[binhpageai]

why github action not support it ? :'(

[kherock]

The fact that customizing the [OPTIONS] portion of docker create is supported and not the commands of the image being tested was very surprising (and disappointing) to find out. The lack of support for this kills most of my potential use of the jobs.<job_id>.services.<service_id> syntax 😔

[ericsciple]

Hi everyone 👋

Thank you for all the feedback here and across the related threads. Building custom wrapper images just to pass flags to a database or start a service shouldn't be necessary. We've been working on a solution and would love your input.

The problem

Service containers have no way to pass arguments to the image entrypoint. The docker create command expects args after the image name:

docker create [OPTIONS] IMAGE [COMMAND] [ARG...]

Every key in the YAML maps to Docker options before the image name. Nothing maps to [COMMAND] [ARG...] after it:

services:
  <service_id>:
    image: string
    env: { key: value }
    ports: [ string ]
    volumes: [ string ]
    options: string      # Maps to [OPTIONS]
                         # Nothing maps to [COMMAND] [ARG...]

This forces workarounds for common scenarios like passing --sql_mode to MySQL or starting MinIO with server /data.

What we're proposing

We're adding two new keys to service containers: command and entrypoint.

Passing flags with command — most scenarios only need command. The image already has the right entrypoint, you just need to pass flags:

services:
  mysql:
    image: mysql:8
    command: --sql_mode=STRICT_TRANS_TABLES --max_allowed_packet=512M
    env:
      MYSQL_ROOT_PASSWORD: test
    ports:
      - 3306:3306

Resulting docker create:

docker create --name <id> --label <label> --network <network> --network-alias mysql -e MYSQL_ROOT_PASSWORD=test -p 3306:3306 mysql:8 --sql_mode=STRICT_TRANS_TABLES --max_allowed_packet=512M

Overriding entrypoint — when you need to swap the image entrypoint, use entrypoint (with or without command):

services:
  etcd:
    image: microbox/etcd:2.1.1
    entrypoint: etcd
    command: >-
      --listen-client-urls http://0.0.0.0:2379
      --advertise-client-urls http://0.0.0.0:2379
    ports:
      - 2379:2379

Resulting docker create:

docker create --name <id> --label <label> --network <network> --network-alias etcd --entrypoint "etcd" -p 2379:2379 microbox/etcd:2.1.1 --listen-client-urls http://0.0.0.0:2379 --advertise-client-urls http://0.0.0.0:2379

The names and behavior match Docker Compose, so if you've written a docker-compose.yml this should feel familiar.

Key points:

• Additive, opt-in — existing workflows continue to work unchanged
• Service containers only — scoped to databases, caches, emulators, and other sidecars
• Overriding entrypoint via options: --entrypoint <binary> continues to work, but entrypoint is more discoverable

Does this address your needs?

We think this covers the core scenarios (database flags, service configuration, custom entrypoints) but want to make sure we're not missing anything. Does this solve your use case, or is there a scenario where you'd still need a wrapper image?

Thanks again for all the feedback and patience. We're looking forward to hearing your thoughts!

— The GitHub Actions Team

[ericsciple]

@maekind i didnt receive an email. I checked spam folder too 🤔

[ericsciple]

I will just roll out the feature flag broadly tomorrow.

[maekind]

Thanks @ericsciple ! It's working as expected 🙏🏻

[ericsciple]

The feature flag is fully rolled out now for everyone

[ericsciple]

Will update autocomplete in the web editor and VSCode. Also, docs updates and changelog landing soon.

[jbebe]

While it's not available, I found a good old "mysql escape" solution. This is the service start command:

/usr/bin/docker create \
    --name ... \
    --label ... \
    --network ... \
    --network-alias ... \
    $OPTIONS \
    -e GITHUB_ACTIONS=true -e CI=true ...

And this is the options value:

services:
  <imagename>:
    image: <imageurl>
    options: >-
      -e GITHUB_ACTIONS=true -e CI=true <imageurl>
      <imagename> --param1 --param2 --param3 #

This way when the options string is injected into the command, we can change the order of arguments with it and then comment out every remaining arguments.