Methods to use the docker picture to run Github Actions? Methods to use them to hurry up the flows and stabilize checks? And when you shouldn’t use them?
This text assumes you have got prior data of github actions and what Docker is. When you want a newbie’s tutorial for github actions, click on right here.
Docker photos are a good way to create consistency and keep away from advanced setup processes. As an illustration, in Vivid we’re utilizing a picture to run our visible regression checks. This reduces the flakiness which may come up from completely different OS variations, completely different browser variations and even lacking fonts on varied machines. It will also be used to boost a DB picture with pre-made knowledge to run checks on throughout your CI/CD course of.
Listed here are two methods of utilizing them in Github Actions.
Methods to Run Your Workflow on Your Personal Docker Picture?
This one is simple. When you choose a machine to run your workflow on, you can too state the picture you wish to use. In Vivid now we have our personal picture that already has playwright put in. This manner, we will run the checks domestically identical to we run them within the CI and it doesn’t matter what machine the developer is utilizing.
Right here’s the workflow file:
identify: 🎨 Take a look at Visible Regression
on: workflow_call
jobs:
check:
runs-on: ubuntu-latest
container: drizzt99/vonage:1.2.0
steps:
- run: echo "Operating 1.2.0"
- makes use of: actions/checkout@v3
- makes use of: actions/setup-node@v3
with:
node-version: '16'
cache: 'npm'
- run: apt-get set up tar -y
- makes use of: actions/cache@v3
id: cache
with:
path: node_modules/
key: ${{ runner.os }}-${{ hashFiles('package-lock.json') }}
- identify: Set up Dependencies
if: steps.cache.outputs.cache-hit != 'true'
run: npm ci
- run: npm run nx e2e elements -- --task=native
- makes use of: actions/upload-artifact@v3
with:
identify: visual-regression-artifact
path: test-results/Within the code snippet above, we see our entire visible regression movement. You possibly can see the total file right here.
You possibly can see the on: workflow_call that states this can be a reusable workflow.
The docker “magic” occurs within the following line:
container: drizzt99/vonage:1.2.0
This tells github actions to run the check in a container of the picture acknowledged on this line. The drizzt99/vonage:1.2.0 picture is revealed to the docker hub (you would use your personal non-public hub) and pulled by github actions for you in the course of the run (with varied optimizations and caching to make this tremendous quick.
From then on, all of the job runs on this picture.
Methods to Run Providers in Containers Throughout a Workflow?
Now let’s say you wish to run a service in opposition to a postgress DB. You could possibly elevate a DB and populate it with knowledge on the run. You could possibly additionally setup a mock DB docker picture and set it as a service obtainable on your workflow.
jobs:
container-job:
runs-on: ubuntu-latest
companies:
communication-db:
picture: drizzt99/communication-db
env:
POSTGRES_PASSWORD: {{ secrets and techniques.COMMUNICATION-DB-PASSWORD }}
ports:
- 5432:5432
steps:
- identify: Try repository code
makes use of: actions/checkout@v3
- identify: Set up dependencies
run: npm ci
- identify: Run my service check
run: npm run test-communication-service
env:
POSTGRES_HOST: localhost
POSTGRES_PORT: 5432The brand new property right here is companies. On this property, we state varied containers that shall be obtainable for the primary course of. On this case, we arrange our DB:
The service’s label communication-db is ready and beneath it, we state the picture we’d like to make use of (on this case, a pre-made picture of a DB), go surroundings variables (on this case, a password we saved as a repository secret), and a ports property. The ports property maps tcp port on the db container to the host.
Lastly, we use the DB in our check. Notice that we use localhost as a result of github actions maps the ports in response to the ports property.
Notice that we will additionally use our personal container to run the movement as we did within the former part by including:
container: drizzt99/communication-service
to our job.
On this case, github actions maps all of the ports automagically between companies and the primary container so we don’t must map our container. The configuration will seem like this:
jobs:
container-job:
runs-on: ubuntu-latest
container: drizzt99/communication-service
companies:
communication-db:
picture: drizzt99/communication-db
env:
POSTGRES_PASSWORD: {{ secrets and techniques.COMMUNICATION-DB-PASSWORD }}
steps:
- identify: Try repository code
makes use of: actions/checkout@v3
- identify: Set up dependencies
run: npm ci
- identify: Run my service check
run: npm run test-communication-service
env:
POSTGRES_HOST: communication-db
POSTGRES_PORT: 5432When To not Use Your Personal Docker Pictures in Github Actions?
On September sixteenth I talked about optimizing github actions in code.talks 2022 in Hamburg. After the speak, folks approached me for questions past the scope of the quarter-hour Q&A. Considered one of them requested me about ARM structure.
I didn’t have prior expertise with it, and he defined that you simply can’t run a docker picture created on an ARM machine on a distinct structure with out establishing an emulator. Apparently, the set up of the emulator and dealing with the picture utilizing the emulator made a course of that takes minutes take virtually an hour.
On this case, I provided the next resolution – don’t run your ARM setup on github actions machines. You possibly can set off a name for an ARM structure machine set in your cloud supplier and await a response to proceed the remainder of the motion’s movement.
One technique to do it’s to arrange an HTTP request out of your motion. You could possibly do it in some ways: from utilizing curl, by means of customized nodejs code, to utilizing a customized motion that does that just like the http-request-action. Name the distant machine, await its response and use the information in the remainder of the movement. Quicker, cleaner and easier.
The ARM structure is one instance, however I consider any instance with a big useful resource overhead would fall into that class. The github actions machines are moderately fundamental in computational energy, so maintain that in thoughts.
An instance from our setup is our try to extend the variety of visible checks parallel processes. Playwright has a built-in parallelism mechanism, so as an alternative of operating the checks serially, you would run them 3 or extra on the identical time. Regionally on a robust fashionable laptop computer, it really works nice – however once we tried to run 10 parallel processes on a github actions machine, it took longer than operating them serially. That’s as a result of it consumed extra assets than the fundamental github actions machine had.
Abstract
In a earlier article I shared 7 ideas and methods I want I knew earlier than beginning with github actions. I went over utilizing a docker picture in a shallow method. On this article, we noticed to run our movement utilizing a docker picture and the way to use photos as companies for use in our movement.
Utilizing docker is the trade normal for encapsulation and fast setup of advanced configurations. You should utilize it to permit builders to run varied environments on their finish machine, enhance CI/CD stability and deploy entire contained companies to manufacturing.
There’s a couple of use case wherein you shouldn’t use you container or service straight in github actions. That’s because of easy efficiency measurements – github actions are supposed to automate easy processes. Extra advanced ones ought to be delegated to exterior – extra highly effective – machines.
Thanks loads to Yuval Bar Levi for the type and thorough evaluate of this text
