Pre‐built static binaries

Setup

Generally, for things that are static binaries (already compiled), we'll just use the latest Ubuntu Docker image.

We use GoReleaser Pro to configure how the package is built. This allows us to define some shared configuration, so that we only need to implement the things that are specific to this package.

This will allow us to build .apk, .deb, and .rpm packages for both linux/amd64 and linux/arm64 builds.

Downloading from GitHub

For packages that already publish builds as GitHub releases, we use download-asset to download the asset, extract it, and pull out the binary we care about.

To do this, we define a new download.sh file. This file calls download-asset to perform the downloads. The download.sh file is executed by GoReleaser as a pre-build step.

Creating package definition

You'll need a few pieces of information.

• The name of the binary.
• The owner/repository of the GitHub repository.
• The URL for the project (might be the GitHub URL).
• The software license for the project.
• The description of the project (often in the upper-right of the project page).
• The pattern for the release asset.
• Determine an appropriate Cron expression for scheduled updates. See Cron expressions for more information.

From the root of the repository, you can run:

go run generate-workflow.go \
    -t _download-and-package.gotmpl.yml \
    -p {package} \
    -r '{owner/repository}' \
    -c '{cron-expression}' \
    ;

This will generate the workflow for Pre‐built static binaries. (Other types of builds will probably have different workflow templates.) Needing to make changes is improbable.

Packaging

Take an existing directory inside the packages/ directory (tenv is a good example), duplicate the directory, and rename it to the name of the package from the previous step.

Ideally, I've been able to abstract-away anything that isn't directly relevant to this one package. There are two files you'll need to edit:

.goreleaser.yml

.goreleaser.yml contains the information that is related to packaging metadata: the name of the package, its URL, license, description, etc. You identified these in the earlier step; you just need to fill them in.

download.sh

This leverages download-asset (which is preinstalled) to perform the downloads and extractions. Here, you'll need to know:

• the owner/repository
• the pattern of the GitHub release asset (one for Intel64, one for ARM64)
• the name of the binary inside of the tarball (or blank if the asset itself is a binary)
• and the name to give the binary when it is extracted and saved to the file system

Note

Pattern is {package}_arm64 and {package}_amd64. Anything else will require writing custom code.

Uploading to repository

This automatically handled by the workflow.