Autorelease for other CI platforms

[dwhswenson]

With Travis-CI offering less support for open source projects, I'm forced to move my projects to other CI providers. I'm starting with the migration of Autorelease, because once Autorelease is migrated, it is easy to move my other projects. Here's the current progress on this.

Azure DevOps pipelines

I started out by trying to create Azure pipelines. The advantage of Azure is that it is extremely flexible, and is much better than Travis was for creating modular workflows.

In order to avoid always adding an Autorelease stage to a pipeline (thus cluttering the user experience during normal PRs), we want the decision of whether to include a stage to happen at "compile time" for the CI script, not during the run. Azure has a way of doing this, with the template expression directives (i.e., - ${{ if ... }}). However, it turns out the name of the branch we're merging into, which is one of the main things Autorelease uses to determine behavior, is only known at runtime in Azure (System.PullRequest.TargetBranch). I've implemented a sort of sloppy Azure pipelines version (not fully tested), but this issue led to me switching over to GitHub Actions.

GitHub Actions

I think we'll probably use GitHub Actions. GitHub Actions has the advantage that it is nicely tied into the GitHub ecosystem (and Autorelease currently only knows how to cut releases for GitHub, using the GitHub API). It's one click to the logs, unlike Azure and Travis.

The biggest disadvantage of GitHub is that is treats Autorelease as a workflow, not a collection of Actions. In particular, the ability to select a branch comes at the workflow level. Currently, there doesn't seem to be the ability to directly import workflows from other repositories. So this means that people will have to vendor the Autorelease workflows. Given that, I think my goal will be for user setup to be: (1) run a script to add the vendored Autorelease YAML files; (2) add secret environment variables in the CI interface; (3) add public environment variables in a file in the repository base directory.

Additionally, GitHub Actions is pretty young and developing rapidly. I wouldn't be surprised if it added more functionality for sharing entire workflows soon. (It seems that they've already added the ability to share workflows within an organization).

I'm currently finishing up support for GitHub Actions, which will be part of Autorelease 0.3 (the rest of 0.2.x is testing GitHub actions). However, I've also added partial support for Azure DevOps Pipelines, which I won't remove (and might improve later).

[dwhswenson]

Since #78 (in release 0.2.4), vendoring of GitHub actions have been supported through the command autorelease vendor actions, if Autorelease is installed locally. This makes it easy to update to new versions of Autorelease: update your local install, and run the vendoring command.