Posts on rmqa.com

A Real Release Checked With rmqa, ukue 0.1.0 From GitHub

Sun, 25 Oct 2026 00:00:00 +0000

The other use cases on this site use a made-up tool so the mistakes can be planted on purpose. This one is a real release: ukue, a job queue that lives in one SQLite file, published on GitHub as five archives and a checksums file. Like rmqa, it’s a SoftDevStudio.com project, and its releases are built by a workflow nobody watches.

Writing the Manifest

The files came straight from the release’s download links. Then:

Checking a Draft GitHub Release Before Anyone Can Download It

Sun, 25 Oct 2026 00:00:00 +0000

Many projects don’t publish releases straight from CI. A tool such as GoReleaser builds everything and uploads it to a draft release on GitHub. A maintainer looks the draft over, edits the notes, and presses publish. Until then, nobody else can see it.

That review step is a good idea with one weakness: a person looking at a list of six file names can’t tell what’s inside them. The draft is the last moment a mistake is free to fix, and it’s exactly where an automatic check belongs.

Checking Rust Style Release Targets and a Missing Intel Mac Build With rmqa

Sun, 25 Oct 2026 00:00:00 +0000

Rust projects usually name their release files after target triples: x86_64-unknown-linux-gnu, aarch64-apple-darwin, x86_64-pc-windows-msvc. Each archive also wraps its contents in a folder with the same name, so unpacking tidy-2.3.0-aarch64-apple-darwin.tar.gz gives a folder tidy-2.3.0-aarch64-apple-darwin/ with the program inside. Many projects ship two license files, MIT and Apache.

None of that fits a simple {os}_{arch} pattern, and rmqa doesn’t need it to. Any string you add to a [[platform]] becomes a template variable.

How rmqa Was Tested With 24 Broken Releases and One Bug It Found in Itself

Sun, 25 Oct 2026 00:00:00 +0000

A release checker has one job, and it fails in two ways. It can miss a broken release, which is the reason you run it. Or it can fail a good release, which teaches you to ignore it. The tests for rmqa go after both.

All the numbers on this page come from files in the test/results folder of the code repository. A script runs every test and writes those files, so the site never quotes a number nobody can check.

Keeping a Machine-Readable Record of What Every Release Shipped

Sun, 25 Oct 2026 00:00:00 +0000

Sooner or later someone asks what exactly was in a release. A customer whose security team wants to know which build of a program they’re running. An auditor working through a supply-chain questionnaire. A colleague trying to work out, a year later, whether the Windows download of version 2.3.0 had the fix in it.

The release page answers part of that: file names and sizes. It doesn’t say what was inside the archives, which platform each program was built for, or whether anyone checked. rmqa’s JSON report does, and it costs nothing to keep.

Keeping Env Files and Private Keys Out of Release Archives

Sun, 25 Oct 2026 00:00:00 +0000

Packing scripts are often written as “take this folder and archive it”. That’s fine until the folder holds more than it should. A developer runs the release script locally once, with a .env file sitting in the build folder because the integration tests needed it. A signing step drops its key file next to the program it just signed. A Mac adds .DS_Store files to every folder it opens.

Once a release is public, a secret inside it is public too, and deleting the release doesn’t take it back: mirrors, caches and package managers may already have copies. The only safe time to catch it is before publishing.

Permission Denied After Unzip and How rmqa Spots Lost Executable Bits

Sun, 25 Oct 2026 00:00:00 +0000

On Linux and macOS, a program runs only if its file is marked executable. The mark travels with the file in a tar archive, as part of each entry’s Unix permissions. Lose it, and every user who downloads the release gets the same first experience:

$ ./tidy
bash: ./tidy: Permission denied

Then a support question, or a quiet uninstall.

Two Ways It Gets Lost

Packing with the wrong mode. A script copies the program with a tool or a step that doesn’t keep permissions, or builds the tar archive with fixed file modes, and the program goes in as -rw-r--r--. The archive looks normal, the program is fine, it just won’t start.

rmqa 0.1 Checks a Software Release Before You Publish It

Sun, 25 Oct 2026 00:00:00 +0000

A release is a handful of files. An archive for Linux on Intel, one for Linux on ARM, two for macOS, a zip for Windows, a checksums file. Every one of them was produced by a pipeline that went green, and yet the set can still be wrong in ways nobody looks for: the ARM archive holds the Intel build, the Intel Mac archive still has last week’s program inside, the license is missing from the zip.

What Release Verification Is and Why a Green CI Run Is Not Enough

Sun, 25 Oct 2026 00:00:00 +0000

Most software teams test their code thoroughly. Unit tests, integration tests, linters, type checks, builds on several operating systems. When all of that passes, the pipeline goes green and the release goes out.

But the tests check the code. They don’t check the release. And a release isn’t code: it’s a set of files, assembled at the very end by a few lines of script, that users download and run. Release verification means checking that set of files, as a whole, before it’s published.

Why the Release Checker Is Called rmqa

Sun, 25 Oct 2026 00:00:00 +0000

rmqa stands for release manifest QA. Each part of the name is one idea, and together they describe the whole tool.

Release. Not the build, not the code, not the pipeline. The release is the set of files people download: the archives, the bare programs, the checksums. It’s the one product of a software project that users see directly, and it’s assembled at the very end, often by a script that was written once and rarely looked at again.

Wrong Build in the arm64 Archive Caught Before a Go CLI Release Went Out

Sun, 25 Oct 2026 00:00:00 +0000

Say a small team maintains a command-line tool in Go called tidy. Each release ships five archives, for Linux on Intel and ARM, macOS on Apple silicon and Intel, and Windows, plus a SHA256SUMS file. A release workflow builds them in a matrix of jobs and a final job uploads everything.

One day a refactor of the workflow moves the build output into a shared folder. The Linux ARM job now packs whatever tidy binary is in that folder, and on the runner where it lands, that’s the Intel build. Meanwhile the Intel Mac job hits a cache from the previous release and doesn’t rebuild. Every job is green. The archives have the right names and plausible sizes.