Understanding working with containers

I’m trying to use container in order to run my tests with the GH actions.

In my case it’s wordpress image. And from what I understood, when I use something like

container:
            image: wordpress:5.4.1-php7.2
            env:
                WORDPRESS_DB_HOST: mysql
                WORDPRESS_DB_USER: admin
                WORDPRESS_DB_PASSWORD: ""
                WORDPRESS_DB_NAME: wordpresstest
            ports:
                - 8080:80
            options: --cpus 2

Inside my job, it creates a docker container and mounts my repository.

So every action I do, it’s executed inside that container. When I look at my workflow I can see this

/usr/bin/docker version --format '{{.Server.APIVersion}}'
'1.40'
Docker daemon API version: '1.40'
/usr/bin/docker version --format '{{.Client.APIVersion}}'
'1.40'
Docker client API version: '1.40'
/usr/bin/docker ps --all --quiet --no-trunc --filter "label=c27d31"
/usr/bin/docker network prune --force --filter "label=c27d31"
/usr/bin/docker network create --label c27d31 github_network_a2859660ce99442a8f5f179fc8e48fcf
ea31f6811e5b2cbd9221b99a7dacaefa678843eac55826e20d3eb248dd621e57
/usr/bin/docker pull wordpress:5.4.1-php7.2
5.4.1-php7.2: Pulling from library/wordpress
...
/usr/bin/docker create --name 926fcbe7f7dd4ca1aea989539c0880cc_wordpress541php72_f99692 --label c27d31 --workdir / __w/woo-solo-api/woo-solo-api --network github_network_a2859660ce99442a8f5f179fc8e48fcf -p 8080:80 --cpus 2 -e "WORDPRESS_DB_HOST=mysql" -e "WORDPRESS_DB_USER=admin" -e "WORDPRESS_DB_PASSWORD" -e "WORDPRESS_DB_NAME=wordpresstest" -e "HOME=/github/home" -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work":"/__ w" -v "/home/runner/runners/2.169.1/externals":"/ __e":ro -v "/home/runner/work/_temp":"/__ w/_temp" -v "/home/runner/work/_actions":"/ __w/_actions" -v "/opt/hostedtoolcache":"/__ t" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" --entrypoint "tail" wordpress:5.4.1-php7.2 "-f" "/dev/null"
d9696d02d720aa49acf5eb6fc1f5e81a89299295072f4500ea58188a8f123629
/usr/bin/docker start d9696d02d720aa49acf5eb6fc1f5e81a89299295072f4500ea58188a8f123629
d9696d02d720aa49acf5eb6fc1f5e81a89299295072f4500ea58188a8f123629
/usr/bin/docker ps --all --filter id=d9696d02d720aa49acf5eb6fc1f5e81a89299295072f4500ea58188a8f123629 --filter status=running --no-trunc --format "{{.ID}} {{.Status}}"
d9696d02d720aa49acf5eb6fc1f5e81a89299295072f4500ea58188a8f123629 Up Less than a second
/usr/bin/docker inspect --format "{{range .Config.Env}}{{println .}}{{end}}" d9696d02d720aa49acf5eb6fc1f5e81a89299295072f4500ea58188a8f123629

So it’s like I did

docker run --name test-wordpress -p 8080:80 -d wordpress

on my local machine.

Now, locally, I can exec to that container and I can see the WordPress files installed in the var/www/html folder.

What I’m interested in is: how to do something like that in the action?

I want to run tests, but for that, I need to provide the path to the WP installation. Either that, or I’d need a way to mount my plugin inside the container, and I’m not sure if just adding volumes to my container part in the YAML file

volumes: /__w/woo-solo-api/woo-solo-api":"/var/www/html/wp-content/plugins/:rw

will work?

And then, how to run tests inside the container? 

  

@dingo-d ,

If you have installed the required tool on the host machine and also know the installation directory of the tool, you can try using the syntax “jobs.<job_id>.container.volumes” to set a volume for the tool’s installation directory.

volumes:
  - <source>:<destinationPath>

The <source> is the absolute path of the tool’s installation directory on the host machine, and <destinationPath> is an absolute path you set in the container.

Of course, if the required tool has not been installed on the host machine, you also can add a step in the container job to install the required tool in the container.

About running tests, you just need to execute steps (commands, actions) for the tests in the same container job.

1 Like

Thanks for the explanation :)