Docker action vs composite action

Code to Cloud GitHub Actions
#1

Hi all :slight_smile:

I’m having an internal debate that I’d like to surface to others: what are the “differences” of a Docker action and a composite action?

From my perspective, there seems to be a lot of use cases that could use either or. I’d like to show a couple examples and would like some opinions on what would be the better solution.

Let’s make the assumption a user is not using self-hosted runners. I’d like to ignore JavaScript actions in this use case as well.

To keep it short and sweet, let’s just say we have some entrypoint.sh script that does some “things”.

Here we can create a Dockerfile that starts with a python image and installs the aws-cli and then we run our script:

FROM python:3.8-alpine

RUN pip install --quiet --no-cache-dir awscli

WORKDIR /opt/

COPY entrypoint.sh ./entrypoint.sh

ENTRYPOINT [ "bash", "-c"]
CMD [ "./entrypoint.sh" ]

Of course we would include an action.yaml that would specify we’re using: docker and have some initial setup, but this is the bulk of the work.

If we have a composite action, then we would do something like this:

# --snip--
runs:
  using: composite
  steps:
    - name: Setup Python
      uses: actions/setup-python@v4
      with:
        python-version: '3.8'
    - name: Install aws-cli
      shell: bash
      run: pip install --quiet --no-cache-dir awscli
    - name: Do some work with entrypoint.sh
      shell: bash
      run: ${{ github.action_path }}/entrypoint.sh

Or even something (more minimal) like this:

# --snip--
runs:
  using: composite
  steps:
    - name: Setup aws-cli
      uses: some-org/setup-aws-cli@v1
    - name: Do some work with entrypoint.sh
      shell: bash
      run: ${{ github.action_path }}/entrypoint.sh

This brings me to my main question: at what point do we (as a community) should we decide on what to use? What has been peoples’ determining factors on which action to build?

Thanks for reading and your thoughts!
Jef

1 Like
#2

If you install tools or otherwise would need to modify the setup (without that being the point of your action), a Docker action is probably the way to go. For example, your first composite action example calls actions/setup-python. If the workflow also calls this it a different Python version things could get messy. In that situation the Docker environment lets you install and call whatever tools you need without affecting the environment on the runner.

1 Like