GitHub Releases present a straightforward to entry methodology for finish customers to obtain versioned software program binaries. You can create them manually, but it surely’s a lot simpler to let GitHub Actions construct them robotically utilizing launch tags created in your repository.
Using Tagged Releases
Tags are an current function in Git, with prolonged assist provided by GitHub with Releases, which supply a spot to host binaries with related changelogs.
You can create a tag very like you’d make a department, besides it’s a set level that doesn’t transfer and at all times factors to a particular commit. This is beneficial for creating versioned releases, and most of the people will create tags utilizing semantic versioning format (Major.Minor.Patch).
Tags could be pushed to GitHub the place they can be utilized in different automation workflows. In this case, we will likely be organising a GitHub Actions script that can pay attention for commits containing tagged releases and robotically publish the construct artifacts to a launch.
Setting Up GitHub Actions
First, you’ll need to be sure to have a working GitHub Actions construct, and that your construct scripts are functioning correctly. The precise setup on your workflow will depend upon what sort of mission you’re constructing, however usually, you don’t need to be debugging two issues directly, so you must add the discharge publishing as soon as you have already got working artifacts. You can learn our information to organising a GitHub Actions construct to study extra.
The very first thing to do is edit the “on” part of your Actions script to additionally run when Tags are created. By default, you in all probability have the “push” occasion to observe releases or the grasp department. You’ll want to add tags, and set a filter. For all tags, merely use a wildcard:
At the tip of the workflow, after the whole lot is constructed, we are going to create the Release entry. This is a two half step—first, we are going to want to create a brand new Release object with all of the metadata, after which we are able to use the outputted publish URL for this to add the artifacts. You can create a number of add steps in case you have a number of artifacts.
In both case, we are going to need to solely run these steps if the workflow is working due to a tag. We can do that with a easy if test, and test if the github.ref object is a tag, which shops the ref title of the department or tag that triggered the workflow.
The first step is to create a Release object, which could be executed with the next step. The GitHub token doesn’t want to be created manually—it’s a particular token that may at all times be referenced from Actions scripts.
- title: Create Release
if: startsWith(github.ref, 'refs/tags/')
makes use of: actions/create-release@v1
id: create_release
with:
draft: false
prerelease: false
release_name: ${{ github.ref }}
tag_name: ${{ github.ref }}
body_path: CHANGELOG.md
env:
GITHUB_TOKEN: ${{ secrets and techniques.GITHUB_TOKEN }}
Note right here that the changelog for the discharge is saved at CHANGELOG.md, which should exist for the workflow to run correctly. You can edit this with every tag to change the markdown displayed by GitHub on the discharge web page. There are instruments to generate this robotically with commit messages, however most groups can have their very own methodology of managing this anyway.
Next, you can begin importing artifacts. This makes use of the add URL from the earlier step, and also you’ll want to outline a path the place it may be discovered together with the show title for the asset.
- title: Upload Release
if: startsWith(github.ref, 'refs/tags/')
makes use of: actions/upload-release-asset@v1
env:
GITHUB_TOKEN: ${{ secrets and techniques.GITHUB_TOKEN }}
with:
upload_url: ${{ steps.create_release.outputs.upload_url }}
asset_path: Oxide.Ext.Sanctuary/bin/Release/net48/Oxide.Ext.Sanctuary.dll
asset_name: Oxide.Ext.Sanctuary.dll
asset_content_type: software/octet-stream
Note right here that the content material kind is ready to octet-stream, which is typical for binary knowledge like executables and DLLs. If you’re publishing a ZIP or another type of file, you will have to change this, although it solely impacts the visuals on the discharge web page.
Now, you possibly can commit the adjustments to the Actions workflow, after which create a brand new tag and push it to GitHub. You ought to see a brand new workflow run being created, besides as a substitute of working off the grasp department, it’s working due to the tag:
Once it’s completed, you’ll see the discharge within the GitHub sidebar.