Introduction
GitHub enables distributed and collaborative code development. To ensure software works correctly, many projects use continuous integration to build and test each new contribution before including it. The continuous integration service on GitHub is GitHub actions.
Background
GitHub offers testing on Ubuntu, macOS and Windows operating systems. However, there is a wide variety of other operating systems and you may want to ensure that an open source project developed on GitHub runs well on another operating system, in particular Fedora Linux.
Podman is a command line tool that can run a different Linux operating system in a container. This provides a convenient way to test software on other operating systems. The article Getting Started with Podman in Fedora Linux introduces how to run Podman on Fedora.
This article demonstrates how to run Fedora Linux in a container using Podman. The host operating system can be any distro that has Podman installed, even macOS or Windows. In the following demo, the host operating system is Ubuntu. This will allow us to test that projects developed on GitHub will work successfully on Fedora, even if Fedora is not available as a base operating system for GitHub actions.
Example GitHub Actions Configuration
As an example, we add continuous integration for Fedora Linux to RedAmber, a project enabling the use of dataframes for machine learning and other data science applications in Ruby. This project relies on Apache Arrow release 10 or greater, so we need to use Fedora Linux Rawhide (F38) since Fedora Linux 37 currently has Apache Arrow release 9 in the Fedora repositories.
GitHub has great documentation on using GitHub Actions. In summary, we need to create a yaml file in the .github/workflows directory of the project, and then enable GitHub Actions if it is not already enabled. A sample yaml file which you can easily modify is below:
name: CI
on:
push:
branches:
- main
pull_request:
jobs:
test:
name: fedora
runs-on: ubuntu-latest
steps:
- name: Setup Podman
run: |
sudo apt update
sudo apt-get -y install podman
podman pull fedora:38
- name: Get source
uses: actions/checkout@v3
with:
path: 'red_amber'
- name: Create container and run tests
run: |
{
echo 'FROM fedora:38'
echo '# set TZ to ensure the test using timestamp'
echo 'ENV TZ=Asia/Tokyo'
echo 'RUN dnf -y update'
echo 'RUN dnf -y install gcc-c++ git libarrow-devel libarrow-glib-devel ruby-devel'
echo 'RUN dnf clean all'
echo 'COPY red_amber red_amber'
echo 'WORKDIR /red_amber'
echo 'RUN bundle install'
echo 'RUN bundle exec rake test'
} > podmanfile
podman build --tag fedora38test -f ./podmanfile
Adding the above yaml file enables testing on Fedora Linux running as a guest on Ubuntu. Similar workflows should work for other projects developed on GitHub, thereby ensuring a wide variety of software will run well on Fedora Linux.
Acknowledgements
Benson Muite is grateful to Hirokazu SUZUKI for creating RedAmber, improving the workflow, and using it to test RedAmber on Fedora Linux.
fwilhe
Its not quite clear to me how podman is better than docker in this case, but I really like how matrix builds in actions allow to test different os versions in containers. For example I use this snippet to test my ansible playbook in different fedora versions:
run-in-container-yum:
runs-on: ubuntu-20.04
strategy:
fail-fast: false
matrix:
version: [latest, rawhide]
steps:
– uses: actions/checkout@v2
– name: Build Test Container Fedora ${{ matrix.version }}
run: docker build –build-arg=VERSION=${{ matrix.version }} -t system-automation-test-fedora${{ matrix.version }} –file test/container/Containerfile.fedora .
– name: Run Test Fedora ${{ matrix.version }}
run: docker run –user user –tty –volume $PWD:/mnt system-automation-test-fedora${{ matrix.version }}
Rodrigo
One of the advantages that I can see in using podman over docker, which the example above does not take advantage of, is using
option to bind the host’s “red_amber” to where ever the working directory will be. This would allow the container to directly access all the checked out content without having to copy them into the container.
The advantage that podman brings over docker here is that when you run docker and expose the host’s filesystem to the docker instance, any time the container creates or writes a file to the host’s filesystem, it will normally does this as a root user, so you host filesystem is littered with root files everywhere. Podman on the other hand translates the root user’s permission inside the container to that of the host’s running user. You can trial this yourself using the following example (not the best practice to have “–privileged”):
You should see the files from where you ran the commend on your host if you run
. If you create a file (
), you should see that the file is present in your host’s filesystem with your host user’s permissions. With docker, you can get around this issue, but you would need to go out of your way to create a user within your docker instance that has the same user ID as the host, and make sure you run everything as that user. I recall that docker also had some option to possibly remap the UID, but I’ve never gone that to work.
Benson Muite
Thanks. This is very helpful when processing data with RedAmber.
Benson Muite
Podman should startup faster than Docker, so if build minutes are limited, this may give an improvement in use of this resource. Using a matrix to test out several Fedora Linux releases is very nice and should also work with Podman. Will incorporate this in testing workflows.
Karlis K.
I’m a bit conflicted on this – on one hand this is an excellent article, on the other hand, even tho GitHub may be the worlds largest host of opensource code across countless projects, GitHub itself is not open source and GitHub actions became available free to everyone just recently (relatively) in the past couple of years. Again tho, I liked the article.
Stuart Gathman
So run podman on your local dev machine via git trigger. No need to depend on github.
Karlis K.
That’s true – I’ve relied only on the absolute bare basic usage of Git for so long that I’ve forgotten about all the other core features of Git! I was actually trying to subly, abeit unclearly, nudge towards GitLab (which admittedly originally started out as a commercial product alternative to GitHub) – the FOSS alternative to GitHub.
Benson Muite
Glad you liked it. There are other code hosting and continuous integration solutions. However, one is can not always determine where a project is hosted.