Repository navigation
oakum 0.7.0
Changed
A git listing that skipped part of what it was asked for is unverified (exit 2) instead of read as complete. Three cases that exited 0 before:
- A tag listing beside
warning: ignoring broken ref(a tag ref holding garbage, or one git cannot read). git lists the other tags and exits 0, so the missing tag could be the last release. - A worktree listing beside git's bare
<path>: <system error>line, such asbeta/src/lib.rs: Permission denied.git statusdrops a file it cannotlstatthat way, so a changed package went unseen. Other unprefixed stderr, such as a clean filter's own output, still leaves the listing standing. - A tag listing that
git refs verifysays could not open a directory under the repository'srefs/tags, wherever its git directory lives: beside the worktree, inside a submodule's parent, or a separate git dir. git drops the tags in that directory without a word, and an empty listing read as never released. oakum now runsgit refs verifyafter every tag listing. A git directory kept under a folder path holdingrefs/tagscan't be told apart, so there an unopened directory in another namespace is unverified too. Its warnings about a ref's form, such as a missing newline or a symlink, change nothing. On a git older than 2.47, which has norefs verify, the listing stands as before.
A clone whose remote fetches only some branches (git clone --single-branch) is unverified (exit 2) where oakum reads every tag (release's check of local tags and migrate's tag-format derivation), instead of read as a complete tag set. git follows only the tags on the branches it fetches, so a release tagged on another branch was missing and the short set read as the whole. Readers of the tags on HEAD's history (check, version, reachable-tags) are unaffected: the fetched branch brought every tag on it.
oakum judges the remote it reads tags from (origin, else the first by name). It reports when no fetch refspec stores every branch, a negative refspec takes some branches back, or the remote has no refspec at all, unless tagOpt is --tags or a refspec stores every tag under refs/tags/. The message names the refspec and the fix: git config --replace-all remote.<name>.tagOpt --tags, then git fetch --tags -- <name>. actions/checkout at fetch-depth: 0 keeps the refspec for every branch and is unaffected.
The --no-tags check now follows what git fetches, too: a tagOpt value git does not recognise no longer hides an earlier --no-tags, a git clone --mirror (whose refspec stores every tag) is no longer reported as tag-suppressed, and a negative refspec that takes tags back counts against it. Remote settings are read with git config -z, so a remote whose name holds a space no longer breaks the read.
Known limits. Both checks read what the next fetch would bring, not what the last one did, so a remote widened (or set to tagOpt --tags) but not yet fetched reads as whole. In a single-branch clone, checking out a branch fetched by name into FETCH_HEAD alone leaves the tags on it unfetched, and the HEAD readers do not notice.
A bump-file note that keeps one section and loses another is now caught, as one that loses them all already was. A heading with nothing under it reaches no changelog, and when another heading in the same note rendered, the release looked complete while the empty section disappeared without a word. add refuses such a note before writing, and check reports it (refusing under --strict), each naming the empty heading: "has a heading with nothing under it (### Fixed)". A note that opens with a heading, an empty note, and a coverage-only note are unaffected.
add refuses, before writing, a bump file that releases a package the config does not version: one include/exclude leaves out, or a private package without private-packages.version = true. status, check and version all refused that file, so it could never release; the refusal now comes while the author is still there, naming the setting. A name:none entry is still written, since it releases nothing. check now accepts such an entry too: it refused one that status and version accepted.
With commits-only intent, a commit whose scope names a package the config keeps but cannot version is reported rather than dropped without a word. status prints "Named by a commit but not version-managed". status --json, the commit-message and title templates, and the version pull request's body carry it as named_unmanaged, and the ci pr-status comment lists it. check, version and ci version-pr print it on stderr without gating, --strict included, whether or not anything releases. A package already listed as changed but not version-managed is not repeated, and an excluded package stays silent.
Install oakum 0.7.0
Install prebuilt binaries via shell script
curl --proto '=https' --tlsv1.2 -LsSf https://github.com/oakoss/oakum/releases/download/v0.7.0/oakum-installer.sh | shInstall prebuilt binaries via powershell script
powershell -ExecutionPolicy Bypass -c "irm https://github.com/oakoss/oakum/releases/download/v0.7.0/oakum-installer.ps1 | iex"Install prebuilt binaries via Homebrew
brew install oakoss/tap/oakumInstall prebuilt binaries into your npm project
npm install @oakoss/oakum@0.7.0Download oakum 0.7.0
| File | Platform | Checksum |
|---|---|---|
| oakum-aarch64-apple-darwin.tar.xz | Apple Silicon macOS | checksum |
| oakum-x86_64-apple-darwin.tar.xz | Intel macOS | checksum |
| oakum-x86_64-pc-windows-msvc.zip | x64 Windows | checksum |
| oakum-aarch64-unknown-linux-gnu.tar.xz | ARM64 Linux | checksum |
| oakum-x86_64-unknown-linux-gnu.tar.xz | x64 Linux | checksum |
| oakum-x86_64-unknown-linux-musl.tar.xz | x64 MUSL Linux | checksum |
Verifying GitHub Artifact Attestations
The artifacts in this release have attestations generated with GitHub Artifact Attestations. These can be verified by using the GitHub CLI:
gh attestation verify <file-path of downloaded artifact> --repo oakoss/oakumYou can also download the attestation from GitHub and verify against that directly:
gh attestation verify <file-path of downloaded artifact> --bundle <file-path of downloaded attestation>