A few years ago I did my first steps with GitHub actions - very basic at first, just to do some syntax validation. Over the years the workflows have slightly increased in complexity as the use cases have grown (although I definitely prefer GitLab's CI/CD pipeline over GitHub actions).
But I recently ran into a new problem: I needed to run integration tests on multiple Linux distributions.
When defining a new GitHub workflow, each job inside a workflow has the configuration option of "runs-on", which represents the "OS selector"; on which OS should the code be executed.
The following example is from the check_smart repository, executing the check_smart.pl monitoring plugin with --help (and therefore doing a basic syntax validation of the Perl code). This job "validate" runs on the latest Ubuntu version, which can be seen in the "runs-on" line:
$ cat .github/workflows/launchhelp.yml
# @file launchhelp.yml
---
name: Launch help
# Trigger the workflow on push or pull request
on: [push, pull_request]
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Install perl
run: |
sudo apt-get install -qq -yy perl
- name: Launch script with --help
run: |
./check_smart.pl --help
Having worked with Travis CI deployments and GitLab CI/CD pipelines, I was used to just select any Linux distribution. But in the case of GitHub workflows the possible values for "runs-on" (so-called "runner images") are very limited. The documentation currently mentions the following supported Linux distributions and versions:
On the Linux side this currently gives us only one distribution: Ubuntu. And from Ubuntu we can currently choose between the two currently active LTS versions 20.04 (Focal) and 22.04 (Jammy).
But what if the code needs to be tested against a RPM-based Linux distribution, such as Rocky Linux or CentOS?
One possibility would be that you create a self-hosted runner and use this as value in the "runs-on" configuration. But there's a much easier way.
We can use the Ubuntu OS from the runner image to start (nested) containers with the wanted Linux distribution.
The GitHub documentation mentions jobs.<job_id>.container.image as configuration key:
Use jobs.<job_id>.container.image to define the Docker image to use as the container to run the action. The value can be the Docker Hub image name or a registry name.
In the following example I use the rockylinux:9 Docker container image from Docker Hub:
$ cat .github/workflows/rockylinux9.yaml
# @file rockylinux9.yml
---
name: Tests on Rocky Linux 9
# Trigger the workflow on push or pull request
on: [push, pull_request]
jobs:
distribution-check:
runs-on: ubuntu-latest
container:
image: rockylinux/rockylinux:9
steps:
- uses: actions/checkout@v1
- name: Are we really on Rocky Linux?
run: |
cat /etc/os-release
The job "distribution-check" runs on Ubuntu latest but then launches the defined container image. The steps below it are executed inside the container. The one step defined in this job simply executes cat /etc/os-release inside the container's Shell environment. This should give us a quick verification whether we are really executing code inside the Rocky Linux 9 container.
Once committed to the repo, the GitHub workflow is automatically triggered and the output can be verified in the browser (under the "Actions" link in the repository):
Yep, we are indeed executing commands inside Rocky Linux 9!
Obviously this works for all kinds of Docker images, not just from Rocky Linux on Docker Hub. You can also define your own Docker image registry and even use login credentials (using jobs.<job_id>.container.credentials) if you have a private repository on a Docker image registry.
No comments yet.
AWS Android Ansible Apache Apple Atlassian BSD Backup Bash Bluecoat CMS Chef Cloud Coding Consul Containers CouchDB DB DNS Database Databases Docker ELK Elasticsearch Filebeat FreeBSD Galera Git GlusterFS Grafana Graphics HAProxy HTML Hacks Hardware Icinga Influx Internet Java KVM Kibana Kodi Kubernetes LVM LXC Linux Logstash Mac Macintosh Mail MariaDB Minio MongoDB Monitoring Multimedia MySQL NFS Nagios Network Nginx OSSEC OTRS Office OpenSearch PGSQL PHP Perl Personal PostgreSQL Postgres PowerDNS Proxmox Proxy Python Rancher Rant Redis Roundcube SSL Samba Seafile Security Shell SmartOS Solaris Surveillance Systemd TLS Tomcat Ubuntu Unix VMWare VMware Varnish Virtualization Windows Wireless Wordpress Wyse ZFS Zoneminder