GitHub Actions: Use Podman to run Fedora Linux

An image showing boxes on a conveyer belt. After passing a magnifying glass, the box has a check mark. Below the conveyor belt is text "Ensuring a Fedora Software Pipeline".

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.

Fedora Project community

8 Comments

  1. 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

      --volume

      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”):

      podman run -it -v ${PWD}:/workspace -w /workspace --privileged busybox

      You should see the files from where you ran the commend on your host if you run

      ls

      . If you create a file (

      touch hello

      ), 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.

    • 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.

  2. 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.

    • 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.

    • 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.

Comments are Closed

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions