From bf79a2258479b302bf6fc4ba5afac1daad2b76fe Mon Sep 17 00:00:00 2001 From: m5r Date: Sat, 12 Sep 2026 00:38:45 +0200 Subject: [PATCH] docs: renovate's nix manager does not bump a tag ref; the regex manager recipe that does --- docs/how-to/install-with-nix.md | 22 ++++++++++++++++------ specs/milestone-40.md | 2 ++ 2 files changed, 18 insertions(+), 6 deletions(-) diff --git a/docs/how-to/install-with-nix.md b/docs/how-to/install-with-nix.md index de961b2..a7178e2 100644 --- a/docs/how-to/install-with-nix.md +++ b/docs/how-to/install-with-nix.md @@ -1,6 +1,6 @@ # Install nxdns with Nix -Adds nxdns to a NixOS machine as a flake input pinned to a release tag. At the end `pkgs`-style references to `inputs.nxdns.packages.${system}.default` resolve to the published release binary, and Renovate opens a pull request when a new tag appears. +Adds nxdns to a NixOS machine as a flake input pinned to a release tag. At the end `pkgs`-style references to `inputs.nxdns.packages.${system}.default` resolve to the published release binary, and a Renovate custom manager opens a pull request when a new tag appears. nxdns publishes its own `flake.nix`. Its packages do not build nxdns from source: each one fetches the release tarball for the target and pins its SHA-256 hash, so a changed byte fails the build. The two supported systems are `aarch64-linux` and `x86_64-linux`, both static musl builds that need nothing on the host. @@ -57,19 +57,29 @@ The derivation installs `bin/nxdns`, plus `LICENSE` and `THIRD-PARTY-NOTICES` un ## 4. Let Renovate bump the tag -Enable the Nix manager in the consuming repository's `renovate.json`: +Renovate's built-in `nix` manager does not do this. It only advances `flake.lock` along the ref an input already tracks, and a `refs/tags/vX.Y.Z` ref never moves, so it reports no releases for a tag-pinned input. Verified on 2026-09-09 with Renovate 42.99.0 against a Gitea host: all flake inputs, GitHub-hosted ones included, came back with an empty release list. + +What works is a regex custom manager that treats the tag in the input URL as a version string, with the `gitea-tags` datasource: ```json { "$schema": "https://docs.renovatebot.com/renovate-schema.json", "extends": ["config:recommended"], - "nix": { - "enabled": true - } + "customManagers": [ + { + "customType": "regex", + "managerFilePatterns": ["/^flake\\.nix$/"], + "matchStrings": ["git\\+https://git\\.mial\\.net/mokhtar/nxdns\\.git\\?ref=refs/tags/(?v\\d+\\.\\d+\\.\\d+)"], + "depNameTemplate": "mokhtar/nxdns", + "datasourceTemplate": "gitea-tags", + "registryUrlTemplate": "https://git.mial.net", + "versioningTemplate": "semver" + } + ] } ``` -Renovate reads the flake inputs and the lock file, sees the `refs/tags/v0.0.16` ref, and opens a pull request when a newer tag exists. It proposes only tags that already exist, so it never pins a release that has not been cut. +Verified on 2026-09-09: with this manager, Renovate opened the pull request for v0.0.18 on the day of the tag. That pull request rewrites the tag in `flake.nix` only. `flake.lock` still records the old revision, so the same pull request must also refresh the lock, either with a `postUpgradeTasks` command (`nix flake update nxdns`, which needs the self-hosted `allowedCommands` setting) or with a CI job on the Renovate branch that commits the lock. The datasource proposes only tags that already exist, so it never pins a release that has not been cut. Between the tag push and the asset upload there is a window in which the tag exists and the release tarballs do not. A pin written by hand during that window evaluates, then fails at build time with a 404 from the release download URL. Wait for the release to be published, or re-run the build once it is. Renovate's own pull requests are not affected by the window in practice, because it runs on a schedule rather than on the tag push. diff --git a/specs/milestone-40.md b/specs/milestone-40.md index 9f9712d..62a557b 100644 --- a/specs/milestone-40.md +++ b/specs/milestone-40.md @@ -81,6 +81,8 @@ Deviation (Session D): the pin stage is tested in pieces rather than on a fixtur Signing the flake outputs, a Hydra or cachix binary cache, Darwin packages, and a NixOS module. Renovate tag discovery on Gitea is a consumer-side acceptance test run once on `rpi.mial.net` after the first tagged release with a flake. +Result of that test (2026-09-09, v0.0.18, Renovate 42.99.0): no pull request. Renovate's `nix` manager advances `flake.lock` along the ref an input already tracks and never moves a `refs/tags/vX.Y.Z` ref; it returned an empty release list for every flake input, GitHub-hosted ones included. The flake itself is correct and v0.0.17 deployed through it. Tag bumps need a regex custom manager with the `gitea-tags` datasource plus a lock refresh in the same pull request, which the consumer owns; `docs/how-to/install-with-nix.md` section 4 now says so instead of claiming the `nix` manager does it. With that manager in place, Renovate opened rpi.mial.net PR 5 the same day, bumping the input to v0.0.18 and refreshing `flake.lock`: the acceptance test passes. + ## Acceptance - `zig build test` green, including the two-path reproducibility test.