Update DeterminateSystems/nix-installer-action action to v21

[renovate]

This PR contains the following updates:

Package	Type	Update	Change
DeterminateSystems/nix-installer-action	action	major	v19 → v21

---

Release Notes

DeterminateSystems/nix-installer-action (DeterminateSystems/nix-installer-action)

v21

Compare Source

What's Changed

• Update to determinate by default by @​grahamc in #​208

• If determinate is false, pass --prefer-upstream by @​grahamc in #​202

• Drop x86_64-darwin by @​grahamc in #​207

• Update detsys-ts: Merge pull request #​109 from DeterminateSystems/tsup-to-tsdown by @​detsys-pr-bot in #​203

• Update detsys-ts: Merge pull request #​114 from DeterminateSystems/dependabot/npm_and_yarn/npm-deps-47c548f420 by @​detsys-pr-bot in #​206

Full Changelog: DeterminateSystems/nix-installer-action@v20...v21

v20

Compare Source

What's Changed

• Update detsys-ts: Merge pull request #​106 from DeterminateSystems/fix-dependabot-warning by @​detsys-pr-bot in #​194
• Update detsys-ts: Capture the version of Nix in addition to the nix store version (#​108) by @​detsys-pr-bot in #​197
• Report the number of nix builds that passed / failed by @​grahamc in #​196
• Record events if authentication is skipped by @​gustavderdrache in #​198
• Treat FlakeHub logins as a funnel by @​gustavderdrache in #​199
• Apply fixups from CodeRabbit review by @​gustavderdrache in #​200

Full Changelog: DeterminateSystems/nix-installer-action@v19...v20

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to 516145f in 3 minutes and 30 seconds. Click for details.

• Reviewed 26 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 2 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. .github/workflows/ci.yml:35

• Draft comment:
  Updated to v21, but note that this release has dropped support for x86_64-darwin. Your CI matrix (lines 23-26) includes a macOS runner using x86_64-darwin. Please verify whether you intend to continue testing on this platform or adjust the matrix accordingly.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This comment has several issues: 1) It asks the PR author to "verify" something, which violates the rule about not asking authors to confirm intentions or double-check things. 2) The comment is speculative - it assumes that v21 dropping x86_64-darwin support will cause an issue, but if this would actually break the CI, it would be caught when the workflow runs. 3) I don't have strong evidence that v21 actually dropped x86_64-darwin support - this is an external claim about a dependency change. 4) The rules explicitly state "Do NOT comment on dependency changes, library versions that you don't recognize, or anything else related to dependencies." This is fundamentally a dependency version upgrade comment. Could the comment be valid if v21 truly dropped x86_64-darwin support and this would cause a silent failure rather than an obvious build break? Perhaps the CI would pass but not actually test what it's supposed to test. Even if there's a potential issue, the comment explicitly asks the author to "verify" which violates the rules. Additionally, if the nix-installer-action doesn't support x86_64-darwin, the CI job would likely fail obviously when it tries to install Nix on the macos-13 runner, which would be caught by the build. The rules say not to comment on things that would be obviously caught by the build. This comment should be deleted because: 1) It asks the PR author to "verify" something, which violates the rules, 2) It's about a dependency version change, which the rules say not to comment on, 3) Any actual incompatibility would be caught when the CI runs, and 4) There's no strong evidence visible in the diff that this is definitely a problem.

2. .github/workflows/devcontainer.yml:37

• Draft comment:
  This update uses a commit hash to reference v21. Consider whether to use the release tag (e.g. @v21) if available for clarity, unless you intentionally prefer a pinned commit hash for security.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The comment is asking the author to "consider whether" to use a different format, which is essentially asking them to confirm their intention or make a judgment call. The PR author clearly updated from v19 to v21 using the same commit hash pattern that's consistently used throughout the entire workflow file for all actions. This is a deliberate and consistent pattern in the codebase. The comment is speculative ("unless you intentionally prefer...") and doesn't point to a clear code issue. It's more of a style suggestion that questions the author's choice without strong evidence that it's wrong. According to the rules, comments that ask the author to confirm their intention or are speculative should be deleted. The comment could be seen as a valid code quality suggestion about using more readable version tags. Using commit hashes is a security best practice in GitHub Actions to prevent tag manipulation attacks, so the current approach might actually be the better choice. While it could be a code quality suggestion, the comment is phrased as asking the author to "consider whether" to change it, which is asking them to confirm their intention. More importantly, the entire file consistently uses commit hashes for all actions, showing this is an intentional pattern. The comment doesn't provide strong evidence that this is wrong - in fact, pinning to commit hashes is a security best practice. This makes the comment speculative and not actionable. This comment should be deleted. It asks the author to consider/confirm their intention rather than pointing to a clear code issue. The use of commit hashes is consistent throughout the file and is actually a security best practice for GitHub Actions. The comment is speculative and not actionable.

Workflow ID: wflow_qwlvRWPVkxkoeE43

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

• 🔍 Trigger a full review

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}