Adopt VERSION-file versioning and dispatch-driven releases - #4
Merged
Merged
Conversation
Ports the versioning and release system from the wakuwi repo: - VERSION file holds the current version (1.3.0-dev); the Makefile and Dockerfile inject it via -X main.version and the server banner prints it - Dockerfile cross-compiles for the target platform from the build platform (no emulation in multi-arch builds) and accepts a VERSION build-arg - release.yml is now workflow_dispatch with a minor/major bump input: it strips the -dev suffix, commits and tags vX.Y.0, bumps VERSION to the next -dev cycle, builds platform binaries, pushes a multi-arch image to ghcr.io/stut/s3dir, and creates a GitHub release with generated notes - docker-publish.yml no longer triggers on tags; versioned images come from the release workflow The next release cut from this will be v1.3.0.
Release images are published to GHCR by the release workflow, so the Docker Hub publish workflow, its setup guides and all references to it are gone.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Ports the versioning and release system from the wakuwi repo.
How it works
VERSIONfile is the single source of truth, holdingX.Y.Z-devduring development — currently1.3.0-devso the next release is v1.3.0. The Makefile and Dockerfile inject it via-X main.version, and the startup banner prints it. A plaingo buildshowsdev.minorormajorbump. It runs the tests, strips-dev, commits and tagsvX.Y.0, immediately bumpsVERSIONto the next-devcycle, builds the five platform binaries, pushes a multi-arch (amd64/arm64) image toghcr.io/stut/s3dirtaggedvX.Y.0+latest, and creates a GitHub release with--generate-notes. No more hand-tagging.$BUILDPLATFORMfor$TARGETOS/$TARGETARCH, so multi-arch builds don't run the Go compiler under QEMU, and accepts theVERSIONbuild-arg.Differences from wakuwi: no UI build steps, no Homebrew tap step, and checkout uses the default
GITHUB_TOKEN— if a branch ruleset is ever added tomain, the release workflow will need a deploy key like wakuwi'sRELEASE_DEPLOY_KEYto push its version commits.Testing
make buildbinary printsVersion: 1.3.0-dev; Docker image built with--build-arg VERSION=1.3.0-testprintsVersion: 1.3.0-test