Skip to content

Release plugin binaries

Axel von Bertoldi requested to merge avonbertoldi/3/release-plugin-binaries into main

This MR adds the ability to build release binaries for this plugin, upload them to Gitlab's generic package registry, and create releases from tags which point to the binaries in the package registry.

The binaries are uploaded to and hosted on GitLab's own generic package registry, and can be downloaded directly form there. Releases are made in GitLab's own release deployments repo. The scripts herein create a release for a specific version, and also for a latest version. The version and latest releases will point to separate package registry artifacts, though their contents will be the same for a latest version and latest. When creating a new latest release, the existing latest release must be deleted first; this is a limitation of API to interact with releases, which does not allow pointing an existing release to new artifacts.

This MR adds the following make targets:

  • build: this just calls go build to build the plugin for the host arch/os
  • all: this build the plugin for all arch/os combinations for which we build gitlatb-runner, using gox
  • all-2: this does the same as all, but using Makefile string manipulation instead of gox. This is something @ajawalker suggested since gox can be slow. Gox is slow, but this approach isn't any faster. it does have the advantage that is has 1 less dependency than the gox approach. We can choose one of the two in the MR and I'll remove the other one.
  • upload-binaries: this target calls a script to upload the binaries built in all using GitLab's API.
  • release: this target calls a script to create a release for the specified git tag (a version tag or latest) using GitLab's release-cli tool, which is included in the registry.gitlab.com/gitlab-org/release-cli image. The script also adds the previously uploaded binaries as release artifacts.
  • do-release: this is a convenience target to kick off making a release. it basically just creates and pushes two git tags; latest and whatever is in the VERSION file.
  • test: this one runs currently non-existing tests
  • shellcheck: this one runs shellcheck on the scripts introduced in this MR

This MR also adds 5 new jobs in 4 stages, all of which correspond to one of the above make targets:

  • test
    • test
    • shellcheck
  • build
    • build
  • upload
    • upload-binaries
  • release
    • release

The jobs in the test stage run on every MR and release tag event (see rules for what constitutes a release tag). The other 3 jobs/stages run only on a release tag events.

Note that even though I've used the gitlab-org tag/label (to use runners from that pool to run pipelines) as suggested in https://about.gitlab.com/handbook/engineering/gitlab-repositories/#cicd-configuration, the job appears to use a single core, which makes the build job dead slow.

Visible outputs of the MR:

I'll delete the tags, binaries and releases when the MR is merged.

❗ Best reviewed commit-at-a-time ❗

Closes #3 (closed)

Edited by Axel von Bertoldi

Merge request reports