Creating GitHub Releases for Multi-git

Creating releases with GitHub Actions

For the purpose of self-updating, we will create official releases when a particular commit is tagged. A good naming convention is to use semantic versioning tags with ...

When you are happy with a particular commit you can tag it like so:

git tag v0.8.18

Pushing the tag is as simple as:

git push --tags

This will trigger the Create Release workflow in on-tag-push.yml. Let’s review it piece by piece. It is triggered by tags that start with lowercase v. This means that you can have additional tags that will not trigger a release.

on:
  push:
    # Sequence of patterns matched against refs/tags
    tags:
      - 'v*' # Push events to matching v*, i.e. v1.0, v20.15.10

name: Create Release

Next, in the jobs section, it defines a build job whose name is also Create Release like the workflow. It runs on ubuntu-latest runner and it defines two environment variables that will be available to all the steps of this job. The secrets.GITHUB_TOKEN is needed to access the GitHub API and thanks to the tight integration with GitHub it is provided automatically.

jobs:
  build:
    name: Create Release
    runs-on: ubuntu-latest
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # This token is provided by Actions
      COMPRESS_FILES: true

Now, come the steps. The first step Checkout code uses a built-in action actions/checkout@v2. There is no need to configure it because it gets all the context it needs implicitly from the workflow context, including repo, branch, etc.

    steps:
      - name: Checkout code
        uses: actions/checkout@v2

The next step, is another built-in action, which creates a GitHub release. It requires some input such as the tag name, the release name, the release description (body), and whether it is a draft or pre-release.

      - name: Create Release
        id: create_release
        uses: actions/create-release@v1
        with:
          tag_name: ${{ github.ref }}
          release_name: Release ${{ github.ref }}
          body: ${{ github.event.head_commit.message }}
          draft: false
          prerelease: false

After this step executes, we will have a GitHub release that contains the source code artifacts. However, we also want multi-git binaries for multiple platforms. In order to do that, we need to cross-compile multi-git. To do this, we can use a custom action called golang-build that I found. Note that it is not available in the community’s Actions Marketplace, which is a good place to start looking for actions.

      - name: Build binaries
        uses: sosedoff/actions/golang-build@master

Once the binaries are built, they are available in the .release sub-directory of the workflow’s workspace. This is just how the golang-build action does it.

The next step is to upload the binaries and add them as assets to the release. We can use the built-in action actions/upload-release-asset. The name of each binary follows this naming convention multi-git_<OS>_<CPU>.zip.

        uses: actions/upload-release-asset@v1
        with:
          # This pulls from the CREATE RELEASE step above, 
          # referencing it's ID to get its outputs object,
          # which include a `upload_url`.

          upload_url: ${{ steps.create_release.outputs.upload_url }}
          asset_path: .release/multi-git_darwin_386.zip
          asset_name: multi-git_darwin_386.zip
          asset_content_type: application/zip

Unfortunately, upload-release-asset allows uploading one asset at the time, so we need to have a separate step for binary. Here is another step:

      - name: Upload multi-git windows_amd64
        id: upload_multi_git_windows_amd64
        uses: actions/upload-release-asset@v1
        with:
          upload_url: ${{ steps.create_release.outputs.upload_url }}
          asset_path: .release/multi-git_windows_amd64.zip
          asset_name: multi-git_windows_amd64.zip
          asset_content_type: application/zip

In the end, this is what the release looks like on GitHub: