Currently there are only two Actions one can create, JS or Docker.
We run everything on a self-hosted linux runner.
I have a custom Docker-image that I use to build. I need to mount specific folders/volumes into this image and also give it the --privileged flag as it is a DinD image.
I have built a workflow that does exactly what I need:
Build: runs-on: self-hosted needs: Cleanup container: image: docker.pkg.github.com/USER/REPO/IMAGE # Using options instead of volumes, due to bug not mounting volumes... # https://github.community/t5/GitHub-Actions/Container-volumes-key-not-mounting-volume/td-p/34798 options: "-v /data/m2:/root/.m2 -v /home/github-runner/.docker:/root/.docker:ro --privileged" steps: - run: /entrypoint.sh
For the workflow, there are the keywords "volumes" and "options" (although volumes does not seem to be functional at the moment). Setting "options" works just as expected.
As we would use this snippet in around 30 Repositories I tried to tidy it a bit by extracting this into an Action, so that the workflow.yml would be much smaller.
The intuitive idea was to create a Docker Action doing this. But Docker Actions are not capable of setting custom Docker options or mounting volumes/folders into the Container. The recommended way around that is to create JS Action that then executes the Docker commands. But isn't this what a Docker Action should be meant for?
Are there plans to add this feature to the Docker Action?
Solved! Solved! Go to Solution.
Actions are meant to be resuable across many different workflows. In the example you have below you are relying on a very specific configuration of the file system in your mounts which could be different across different runner configurations and that would cause your action to fail in those cases. The best way to think about a docker action is as a CLI distribution were you can run the cli and pass arguments rather than as container infrastructure.
Thank You for Your answer!
I could understand the decision to force Action to be a universal compontent that is usable on potentially every workflow. At this point I am missing an option to split workflows to reuse them across dozens of repositories.
Instead of writing all options and all variables in every workflow.yml, it would be great to just include it as a "custom step" to keep the workflow.yml small.
As far as I know there is no such option for now. Is something planned on this matter?