Git Actions CI - johnttaylor/epc GitHub Wiki

I have switched from using a on-premise build server running Jenkins to using GitHub Actions for the repo's CI builds. At the time the EPC was authored I had hands on experience using Jenkins. Since then I have "learned" how to use Git Actions for CI. For those of you that are new GitHub Action - the workflow files are located in the .github/workflows/ directory

Pros

  • Relatively low barrier to entry assuming you have some exposure to basic CI concepts
    • Or said another way, you don't have to expert/experienced DevOps engineer to get the basics up and running.
  • Workflows use YAML syntax which is easy to learn
  • For open source projects, GitHub provides hosted virtual machines to run workflows
    • GitHub Actions also support self-hosted machines as well
  • Seamless integration with GitHub (as opposed to using a tool like Jenkins)
  • Users can create their own GitHub Actions
    • Large community of shared Git Actions (e.g. a quick search turned up Git Actions to install Doxygen and Graphviz on the host runner)
  • Newer technology/paradigm than "older" tools like Jenkins
    • For example, "out-of-the-box" solutions for handling repository permissions, security tokens, etc.

Cons

  • The free host runners are slow. The free host virtual machines are about 4-5x slower than my mini-PC (i7-13700H) that hosted my Jenkins server
    • To mitigate the performance different - it was very simple to run each "compiler" on its own runner in parallel - so my overall build times only went from ~30min to ~40min.
      • Note: I had setup up my Jenkins jobs to run sequentially (because it was easy) and I didn't have multiple host instances available.
  • No direct access to the GitHub host runners. This makes it difficult to troubleshoot failures (e.g. operating system environment differences) when creating workflows.
    • I did find a partial 'workaround' for this see Lessons Learned below

Lessons Learned

  • When building your workflows and/or setting up your host runner - always check (aka search) if there is Git Action available - don't assume that you have to provide your on solution.

    • That said, I was not able to find an off-the-shelf solution for installing the MinGW Compiler on Windows host that can build 32bit binaries.
      • This is on my TODO list to resolve ;-).

  • The free host runners are slow, but you essentially have an unlimited number available - so for a single workflow you can run multiple jobs in parallel and you can have multiple PRs building simultaneously.

  • Had issues with newline translation when the workflow checked out the source code from GitHub repository. The solution to this was to put an explicit step in the workflow job to issue git commands to set the newline translation rules.

        - name: Checkout code
      run: |
        git config --global core.autocrlf false
        git config --global core.safecrlf false
    - uses: actions/checkout@v2

  • Generating the code coverage report was challenging. With Jenkins, its Cobertura plug-in made creating the code coverage report simple, especially with respect to consolidating all of the individual unit test coverage report files into a single report file. . I did not find any direct equivalent to the Jenkin’s Cobertura plugin, - so I ended up using ReportGenerator. Using ReportGenerator, required 'me' generate a single consolidated code coverage report. There were several options - but I settled on using gcovr native ability to consolidate JSON reports. This led to updates to the tca.py utility script that repo's build scripts use when generating code coverage reports.

  • I had to setup Branch Rules (Require a pull request before merging, Require approvals, and Require status checks to pass before merging) in order to trigger my workflow for PRs.

    • I was surprised that I had to enable Require approvals - but it wouldn't work without it checked. When you are a team of one - this is silly - but GitHub allows you to bypass the rule on the PR page if you are an admin user.

    image

  • When using the Windows host runner, I had issues with running python scripts. Ultimately I had to update my build scripts so that all python scripts are launched using via the python executable, e.g. python mybuildscript.py (instead of mybuildscript.py)

  • Troubleshooting failures on the free host runners is painful. I found the following items to help with troubleshooting workflows:

    • There is a Git Action - tmate - that will pause your workflow and allow you to SSH into the host runner

    • You can turn on additional 'debug' information in the workflow logs by setting the ACTIONS_RUNNER_DEBUG and ACTIONS_STEP_DEBUG variables to true. These variables are set via your repo's Settings->Secrets and Variables option

      image