Docker container action - 'right' way to equivalent a volume?

I have a repo I created whose sole purpose is to create a Docker container action that connects to a database (Snowflake) and outputs some data.

I drew heavily from this repo and was able to recreate locally in Docker.

Part of the set up uses a config file. Anyone in our org using this repo will need their own config file. On the repo linked above you can see this in the script where row 5 uses a custom config file.

I’m trying to figure out the equivalent of doing this with gh actions where I have a repo that contains the base image or action, and then in another repo I want to checkout the snowsql action and then when run use a custom config file that I have in my repo that uses the action.

  • ourorg/snowsql # the generic docker container action repo
  • ourorg/my-project-that-uses-snowsql

When I set this up just using Docker on local I have a docker-compose file of the form:

      - ./ssql/config:/home/snowflake/.snowsql/config

Is there an equivalent or ‘right’ way to do this using a custom docker action?

Repo ourorg/my-project-that-uses-snowsql.github/workflows/main.yml looks like this:

on: [push]

    runs-on: ubuntu-latest
    name: Build ssql image
      - name: Checkout # To use this repository's private action, you must check out the repository
        uses: actions/checkout
	with: # Aside, never done this before, don't know if it's right
	  repository: ourorg/ds-ssql-gh-action
	  ref: main
      - name: Build
	uses: ./ # Uses an action in the root directory 

If this repo ourorg/ds-ssql-gh-action has a file ./config and after I checkout ourorg/ds-ssql-gh-action I’d like to run the action / container but before doing so I want to add ourorg/my-project-that-uses-snowsql/config inside the action / container at /home/snowflake/.snowsql/config. LIke with a volume mount in docker-compose.

How can I do this?

You can’t do custom volume mounts in Docker actions. The closest thing I can think of would be to have an input that gives the (workspace-relative) path of the config file to use. Your action could then either call whatever needs the config with appropriate parameters to set the config path, or (if the config path is fixed) copy the file into place within the action container.

Hi @airtower-luna could you expand on this?

copy the file into place within the action container

How?! I don’t understand.

To underline, I am checking out a generic action from another repo, then I with to augment it by copying the config file in the new repo to the action container.

When you run a container action (e.g. uses: my/action@tag) the runner runs that container, mounts the job workspace into it, and makes it the working directory of the container. So the code running inside the container has access to the workspace and can copy a file from there to another location inside the container. Though it’d be preferable to just use the file as is, but if you use a 3rd party tool that uses a fixed path copying might be the easiest solution.

Assuming you have a file my/config.conf in your working directory and my/action defines a config input, you could call your action like this:

- uses: my/action@tag
    config: my/config.conf

The runner defines an INPUT_CONFIG environment variable inside the container that contains the input value, so if your entrypoint is a shell script you could do something like this in there (assuming the tool you’re about to run requires a fixed location):

cp "${INPUT_CONFIG}" "${HOME}/.tool/config"

Or if the tool has a command line parameter to set the config file (better):

tool --config "${INPUT_CONFIG}"

One thing to keep in mind when working with the home directory is that the user and home directory within the container might not be what you expect, see Dockerfile support for GitHub Actions - GitHub Docs, so avoid it if possible. :slightly_smiling_face:

1 Like

This is incredibly helpful! Sincere thank you.

1 Like