Use Cases 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.

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.

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.