Automate Stuffs with GitHub Actions on Publishing AppImage

I was using travis-ci for buidling and releasing AppImage, until I discovered GitHub Actions recent these days. Since the repos are hosted on GitHub, why not take a try on its own CI/CD for my simple jobs?

This article discusses about using GitHub Actions for automating the AppImage build process and release it for users.

What is AppImage you ask, here provides great explanation and samples.

GitHub Actions

FYI, CI/CD stands for "Continuous Integration and Continuous Delivery". In short, CI/CD automates the building and delivering processes to make developers' life easier.

GitHub introduced its own CI/CD named GitHub Actions. By using GitHub Actions, just push your code to the repo, it builds, test, and upload to release automatically for you. But first, a defined workflow is required.

Actions in action

In Actions, there is a concept of workflows and actions. You can say a workflow contains many actions, and each action performs different set of tasks to achieve a particular job. A GitHub repo will have a workflow, but has different actions, which the tasks are written in yaml files.

Take an example, I have a repo contains AppImage building configurations for Opera. A build.sh in root directory tells a Linux machine to build an AppImage package from deb file.

In the repo, I created a directory .github/workflows. Actions will look for this directory, and take actions from all yaml files within. In this case, one yaml file is enough.

I recommend people to take a look on the documentation to familiarise with the syntaxes. Inside the workflows directory, a build.yml file was created. Now, let's go through the flow one-by-one.

.github/workflows/build.yml

name: AppImage Build
on: push
jobs: ...

These are the most basic syntaxes for Actions to perform CI/CD. The syntax is very straightforward: define the action name, when the action starts, and the jobs will be carried out. In this case, the action will start while GitHub senses a push to the repo. Let's continue.

jobs: 

  # This workflow contains a single job called "build"
  build:
    runs-on: ubuntu-16.04

    steps:
    # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
    - uses: actions/checkout@master

    ...

Within jobs, first thing is to give a job named "build", and specify which operating system to do the job. GitHub offers two LTS versions of Ubuntu, Windows Server 2019 and macOS 10.15. The rest of the tasks will be performed under "steps". We have to clarify which branch in our repo is used for building process, the code above checks out the master branch. Let's continue.

    steps:
    ...

    # Runs a single command using the runners shell
    - name: Install required dependencies
      run: sudo apt-get install desktop-file-utils zsync

    # Runs a set of commands using the runners shell
    - name: Download building tools & executing AppImage build
      run: |
        wget -nv -c https://github.com/AppImage/pkg2appimage/releases/download/continuous/pkg2appimage-continuous-x86_64.AppImage
        wget -nv -c https://github.com/AppImage/AppImageKit/releases/download/continuous/appimagetool-x86_64.AppImage
        ./build.sh

For each task, a "name" and either "uses" or "run" tags are required, and only can be used once. First task installs all required dependencies for building AppImage with single command; second task downloads and executes AppImage build, which GitHub allows multi-line commands by putting a pipe | after "run:"

At this moment, an AppImage has been built. So, the artifact(s) should be uploaded to Release page for users to download. Let's continue.

    steps:
    ...
    ...

    - name: Create Release
      uses: ncipollo/release-action@v1
      with:
        allowUpdates: True
        tag: continuous
        name: Continuous build
        prerelease: True
        artifacts: "out/*"
        token: ${{ secrets.GITHUB_TOKEN }}

Luckily, we have someone created a useful Action for handling the task. The Action helps create a release tag and upload the artifact(s). Specify the repo in "uses" tag, and feed in the parameters under "with" tag. More optional parameters is being explained in the repo, do take a look.

One thing to take note is the "allowUpdates" parameter. Some AppImage package contributors tend to upload the latest version under the pre-release tag, replacing the old version. In default, GitHub Actions will cry out loud for existing release tag and refuses to upload the artifact(s). Set "allowUpdates" to True to replace the old version in the same release tag.

Commit change and see

Now, try to commit this change and push to the repo. When GitHub senses the presence of .github/workflows directory in the repo, it will trigger the CI/CD.

Conclusion

That's it! My first transition from travis-ci to GitHub Actions was a success. In my opinion, GitHub Actions is a more convenient choice for building and publishing AppImage packages on my repos.

Through this article, I hope more AppImage package contributors can take advantages of CI/CD to publish their packages faster and easily. And for those who are interested on building AppImage packages, you are always welcomed to the community ;)