Releasing from GitHub

Tools and options to release your code from GitHub to your infrastructure provider.

This public content is an excerpt from Flutter staff GitHub docs. It is published as a reference to show how GitHub is used for inner source at Flutter.

Once a code change is validated via CI the updated version can be packaged as a deployable artefact. Depending on your application this might be a Docker image, a compiled binary, an rpm or jar file, or simply a bundled and minified source file. This package must then be published to a location from which it can be deployed to relevant environments.

  • Use semantic version git tags on your repository to label and trigger alpha, beta and production builds.
  • Build artifacts (and Change Log) can be attached to a repository via a GitHub Release.
  • Releases can be published to various systems as required: external services (e.g. AWS ECR), GitHub Packages, Artifactory and so on. These choices depend on the requirements of the intended deployments and the artefacts can be published to multiple systems as required.

GitHub Releases

GitHub provide in-built ‘release’ functionality where you can create a ‘release’ to package software, along with release notes and links to binary files, for other people to use. Using this feature is recommended.

  • supports change logs and a variety of build artifacts if required.
  • supports pre-release vs release flags.
  • can be both manually created/adjusted and automated via API/workflows.

Publish to AWS

A common choice is to publish release artefacts from a repository into AWS for use within that ecosystem. For example, you might choose to publish a Docker image into the AWS container registry for use in AWS deployments:

  1. Create a workflow that is triggered by a new GitHub Release (the release event).
  2. Authenticate your workflow with AWS using OpenID Connect.
  3. Login and push image to AWS ECR.

GitHub Packages

GitHub Packages is a software package hosting service that allows you to host your software packages privately or publicly and use packages as dependencies in your projects. This is especially useful to publish library packages for re-use across other projects.

Artifactory

An internal Artifactory instance is available if using the self-hosted runners. This is not always recommended as it has more awkward access requirements across the wider group, but there are cases where it the best choice.