Adding a GitHub Action to a repository is pretty easy. You can use the Web UI and click on the Actions menu and select one of the builtin workflows. If you’ve use Azure Pipelines before, then things will feel kind of similar. Both use YAML as the format for describing build workflows, though there are subtle differences.
Using the Web UI is a good way to get started, plus you can use the search field to look for suitable actions. It is just a file though, so you can edit it and commit it just like any other file.
Each workflow is stored in a separate file. These files reside in the special
Here’s a simple workflow:
name: CI on: push: branches: [ master ] jobs: build: runs-on: windows-latest steps: - uses: actions/[email protected] with: fetch-depth: 0 - name: nuget restore run: nuget restore -Verbosity quiet - name: setup-msbuild uses: microsoft/[email protected] - name: Build id: build run: | msbuild /p:configuration=Release /p:DeployExtension=false /p:ZipPackageCompressionLevel=normal /v:m
on is the trigger which will cause this workflow to run. Common triggers include
pull_request, and you can filter triggers to only fire on specific branches. The full list of available triggers are listed in Webhook events.
jobs, you can list one or more jobs. Each job can run on a runner (build agent). Runners can be ones provided by GitHub or yourself. The GitHub hosted runners actually have the same installed software as the Azure Pipelines hosted agents.
A job (eg.
build in the example above) also lists actions under the
steps section. There’s a number of actions provided by GitHub and lots of 3rd party actions too. It’s pretty easy to create a new action. In a future post I’ll give an overview of the custom action I created.
The above workflow does a git checkout (with full history), then restores NuGet packages, ensures
msbuild is available and then runs
Once your workflow file is committed to the repository, you can view the execution history, or edit the workflow through the Actions tab.
Categories: GitHub Actions