Github Actions Download Docker Image
Ortiz Ullery
The following workflow code uses the completed hello world action in the public actions/hello-world-docker-action repository. Copy the following workflow example code into a .github/workflows/main.yml file, but replace the actions/hello-world-docker-action with your repository and action name. You can also replace the who-to-greet input with your name. Public actions can be used even if they're not published to GitHub Marketplace. For more information, see "Publishing actions in GitHub Marketplace."
This first option is as the base for an entire job. Normally a lot of GitHub actions have you start off with an Ubuntu distro as the base for the VM (there are other OS's you can choose from as well) and then add in your container image. But the entire rest of the job uses whatever container you specify as the starting point for all of the rest of the job's steps.
This second option is as an action in the steps for a job. Instead of something like uses: actions/checkout@v2, you can instead specify a Docker image from the hub to run in its place. The problem with this one though is that you have to generate a Docker image that runs specifically like a GitHub action expects. That means things like avoiding WORKDIR and ENTRYPOINT attributes, as they're handled internally by the GitHub Actions worker.
I ended up finding an action available on GitHub by addnab called docker-run-action that works exactly how I wanted. You specify an image, any options, and a list of commands to run with it, and only during that step of the build process is it used.
This one is pretty obvious, it specifies the image that's pulled and used in the docker run command. I'm using mine for Cleaver that's on the public Docker Hub, but you can also use a privately-owned image as well.
Here I'm creating a bind mount from the current workspace to /var/www, which is the working directory that my Docker image expects. github.workspace includes all of the code checked out from our current repo, and I'm mounting that whole directory as that's what my build process expects. Because I'm using a bind mount, anything done to this code will then be available to GitHub Actions in any following step (like a deployment).
This is where I specify the actual commands I want to run against my container image. This action ignores the entrypoint of the container image, so even though normally using docker run aschmelyun/cleaver:latest it would run those three commands, using this action I have to actually specify them out again in the yaml.
Sometimes during a CI/CD process it's helpful to use a ready-made Docker image to run one-off commands and processes. This could be especially helpful if the software you need isn't available on the actions platform, or requires a lengthy setup process that's already written out in a Dockerfile.
Thanks for the answer and the link! Sounds like something that would work for me.
Just to make sure that I get it right: the idea would be that the GitHub Action creates the whole docker image and pushes it to a private registry from where Render can pull it?
Start by creating two repositories for Docker and Helm. In the example below, they will be named after our favorite project, Vegapunk: vegapunk-docker and vegapunk-helm. The Helm repository includes a Helm Chart called turbine, which uses a Docker image called turbine.
Came to report the same issue. Existing implementation of GitHub Action using SonarSource/sonarcloud-github-action@master is suddenly complaining that NodeJS 12 is no longer accepted. The GitHub Action is running on the SonarSource supplied image. Please update the image to use a newer version of Node.
760c119bf3