Skip to content

Fix post-release WinGet automation - #61

Merged
tonythethompson merged 13 commits into
masterfrom
fix/release-pipeline-followups
Jul 30, 2026
Merged

tonythethompson merged 13 commits into
masterfrom
fix/release-pipeline-followups

Conversation

@tonythethompson

@tonythethompson tonythethompson commented Jul 29, 2026 •

Copy link
Copy Markdown
Collaborator

Summary

  • trigger WinGet submission from a successful tag-triggered Release workflow completion, avoiding GitHub's GITHUB_TOKEN event-recursion suppression
  • keep manual dispatch as the recovery path and fail closed for failed, non-push, foreign-repository, and non-tag Release runs
  • remove the obsolete repo input from wait-on-check-action
  • update checkout, Rust cache, artifact upload/download, and wait actions to current Node 24-compatible releases
  • align release and packaging documentation with the actual trigger chain

Evidence

The v0.1.5 Release run reported:

  • event=push
  • head_branch=v0.1.5
  • head_repository=tonythethompson/numan
  • conclusion=success

Those fields satisfy the new gate. The prior release.published trigger did not run because the GitHub Release was created with GITHUB_TOKEN; manual dispatch was required for v0.1.5.

Validation

  • actionlint 1.7.12: passed for all workflows
  • cargo fmt --all -- --check: passed
  • cargo test --locked: passed (407 unit tests plus integration suites; ignored real-Nu/live tests unchanged)
  • git diff --check: passed
  • verified the updated official actions use the Node 24 runtime

Review in cubic

@coderabbitai

coderabbitai Bot commented Jul 29, 2026 •

Copy link
Copy Markdown
Contributor

Review Change Stack

Warning

Review limit reached

@tonythethompson, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 20 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 9ca27d29-feba-4e9b-8c69-20d0091b5d31

📥 Commits

Reviewing files that changed from the base of the PR and between 836fea3 and 9a60847.

📒 Files selected for processing (7)
  • .github/workflows/release.yml
  • .github/workflows/winget.yml
  • README.md
  • docs/PACKAGING.md
  • docs/RELEASING.md
  • docs/plans/2026-07-29-remaining-roadmap.md
  • docs/plans/2026-07-30-consolidated-multi-repo-roadmap.md
📝 Walkthrough

Walkthrough

Changes

Workflow automation

Layer / File(s) Summary
CI and acceptance action updates
.github/workflows/active-plugin-update-acceptance.yml, .github/workflows/ci.yml, .github/workflows/official-registry-acceptance.yml
Checkout, Rust cache, toolchain, and artifact actions are pinned to specific revisions while existing commands and settings remain in place.
Review and release pipeline updates
.github/workflows/claude*.yml, .github/workflows/cline-pr-review.yml, .github/workflows/release.yml
Review and release workflows update action references, wait handling, artifact transfer, and release-readiness marker generation.
WinGet publication flow
.github/workflows/winget.yml, docs/PACKAGING.md, docs/RELEASING.md
WinGet publishing now follows Release workflow completion, validates the originating marker and Windows asset, derives the release tag, and documents the revised sequence.
Cross-repository roadmap documentation
README.md, docs/plans/2026-07-29-remaining-roadmap.md
The README links to a dated roadmap describing cross-repository priorities, 1.0 readiness gates, and deferred work.

Estimated code review effort: 3 (Moderate) | ~20 minutes

🚥 Pre-merge checks | ✅ 8
✅ Passed checks (8 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly matches the main change: post-release WinGet automation and related release flow updates.
Description check ✅ Passed The description is on-topic and accurately describes the workflow, documentation, and action-pin updates in the changeset.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Pipeline Stage Enum Ordering ✅ Passed Diff only touches workflows/docs; no SessionWorkflowStage enum or comparisons were modified.
Gpu/Cpu Runtime Boundary ✅ Passed The PR only changes workflows and docs; no inference/, requirements, main.py, or C# diarization files are modified.
Managed Host Restart Safety ✅ Passed PASS: The PR only changes workflows and docs; no ManagedVenvHostManager/Containerized* code or restart/health paths were modified, so the safety rule is not implicated.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/release-pipeline-followups
✨ Simplify code
  • Create PR with simplified code
  • Commit simplified code in branch fix/release-pipeline-followups

Comment @coderabbitai help to get the list of available commands.

@qodo-code-review

Copy link
Copy Markdown
Contributor

PR Summary by Qodo

Trigger WinGet publish on successful Release workflow completion

🐞 Bug fix ⚙️ Configuration changes 📝 Documentation 🕐 20-40 Minutes


AI Description

• Trigger WinGet submission from a successful tag-triggered Release workflow_run, avoiding
 GITHUB_TOKEN recursion suppression.
• Gate WinGet runs to fail-closed (success + push + same-repo + v*), with manual dispatch as
 recovery.
• Refresh GitHub Actions dependencies and align release/packaging docs with the new trigger chain.
Diagram

graph TD
  A["Tag push (vX.Y.Z)"] --> B["Release workflow"] --> C["workflow_run: completed"] --> D["WinGet workflow"] --> E{"Gate: success/push/same repo/v*"} --> F["winget-releaser action"] --> G["Open winget-pkgs PR"]
  H["Manual dispatch"] --> D
Loading
High-Level Assessment

The following are alternative approaches to this PR:

1. Run WinGet publishing as a job inside release.yml
  • ➕ Single workflow; no cross-workflow event semantics to reason about
  • ➕ Shares the Release workflow context (tag/version) directly
  • ➖ Harder to re-run WinGet independently without re-running the full release workflow
  • ➖ Tighter coupling increases blast radius if WinGet publishing flakes
2. Keep release.published trigger but create Releases with a non-GITHUB_TOKEN identity (PAT/App token)
  • ➕ Simpler trigger condition (native release event)
  • ➕ Avoids workflow_run indirection
  • ➖ Requires managing a long-lived token or GitHub App credentials
  • ➖ Still easy to misconfigure; increases secret handling and audit surface
3. Use workflow_call reusable workflow invoked by Release
  • ➕ Explicit invocation from Release; avoids relying on workflow_run payload fields
  • ➕ Can share inputs/secrets in a structured way
  • ➖ More plumbing (refactoring into reusable workflow) for a relatively small pipeline
  • ➖ Still coupled to Release execution path; rerun story is less direct than standalone workflow_dispatch

Recommendation: The workflow_run approach is the best tradeoff here: it avoids GitHub’s event-recursion suppression when releases are created via GITHUB_TOKEN, preserves a standalone WinGet workflow that can be re-run, and the new fail-closed gate materially reduces accidental/foreign-run publishing risk. The main follow-up to consider is optionally logging the evaluated gate fields (event/conclusion/head_branch/head_repo) for easier incident debugging.

Files changed (10) +41 / -35

Bug fix (2) +19 / -13
release.ymlModernize Release workflow actions and wait-on-check usage +9/-10

Modernize Release workflow actions and wait-on-check usage

• Updates wait-on-check-action and removes its obsolete repo input, plus bumps checkout, rust-cache, and artifact upload/download actions to current releases.

.github/workflows/release.yml

winget.ymlTrigger WinGet publishing via workflow_run with strict gating +10/-3

Trigger WinGet publishing via workflow_run with strict gating

• Switches the workflow trigger from release.published to workflow_run on Release completion and adds a fail-closed gate (success + push + same repo + v*). Adjusts the release tag source to use workflow_run head_branch, while retaining manual dispatch input as a recovery path.

.github/workflows/winget.yml

Documentation (2) +2 / -2
PACKAGING.mdDocument new WinGet trigger chain and recovery path +1/-1

Document new WinGet trigger chain and recovery path

• Updates packaging instructions to reflect that WinGet publishing happens after the tag-triggered Release workflow succeeds, with manual dispatch as fallback.

docs/PACKAGING.md

RELEASING.mdAlign release checklist with WinGet workflow_run trigger +1/-1

Align release checklist with WinGet workflow_run trigger

• Updates the release checklist to confirm WinGet PR creation after successful tag-triggered Release workflow completion (not after release.published).

docs/RELEASING.md

Other (6) +20 / -20
active-plugin-update-acceptance.ymlBump checkout and Rust cache actions +2/-2

Bump checkout and Rust cache actions

• Updates actions/checkout and Swatinem/rust-cache to newer versions for Node 24 compatibility in the acceptance workflow.

.github/workflows/active-plugin-update-acceptance.yml

ci.ymlRefresh checkout and rust-cache across CI jobs +12/-12

Refresh checkout and rust-cache across CI jobs

• Updates actions/checkout and Swatinem/rust-cache versions across test, clippy, fmt, msrv, package, deny, and real-nu-acceptance jobs.

.github/workflows/ci.yml

claude-code-review.ymlUpdate checkout version (Claude review workflow) +2/-2

Update checkout version (Claude review workflow)

• Bumps actions/checkout to a newer release and fixes the missing trailing newline in the workflow file.

.github/workflows/claude-code-review.yml

claude.ymlUpdate checkout version (Claude workflow) +1/-1

Update checkout version (Claude workflow)

• Bumps actions/checkout to a newer release for Node 24-compatible runtime support.

.github/workflows/claude.yml

cline-pr-review.ymlUpdate checkout version (Cline PR review workflow) +1/-1

Update checkout version (Cline PR review workflow)

• Bumps actions/checkout to a newer release while leaving the rest of the review automation unchanged.

.github/workflows/cline-pr-review.yml

official-registry-acceptance.ymlBump checkout and Rust cache actions +2/-2

Bump checkout and Rust cache actions

• Updates actions/checkout and Swatinem/rust-cache to newer versions for Node 24 compatibility in the Stage 1 acceptance workflow.

.github/workflows/official-registry-acceptance.yml

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - I've found 1 issue, and left some high level feedback:

  • The WinGet publish job gating logic assumes tags start with v and uses workflow_run.head_branch as the tag, which may not cover alternative tag naming schemes or non-standard release flows; consider either documenting this constraint explicitly or relaxing the startsWith check to support broader tag patterns.
  • In the WinGet workflow, release-tag falls back to github.event.workflow_run.head_branch when inputs.release_tag is omitted, which will be incorrect for manually dispatched runs on non-tag branches; you may want to make release_tag required for workflow_dispatch or derive the tag more defensively for that case.
  • All updated GitHub Actions are pinned to version tags (e.g., actions/checkout@v7.0.1); for better supply-chain safety you might consider pinning to immutable commit SHAs instead of semver tags, especially for security-sensitive workflows like release and WinGet publishing.
Prompt for AI Agents
Please address the comments from this code review:

## Overall Comments
- The WinGet `publish` job gating logic assumes tags start with `v` and uses `workflow_run.head_branch` as the tag, which may not cover alternative tag naming schemes or non-standard release flows; consider either documenting this constraint explicitly or relaxing the `startsWith` check to support broader tag patterns.
- In the WinGet workflow, `release-tag` falls back to `github.event.workflow_run.head_branch` when `inputs.release_tag` is omitted, which will be incorrect for manually dispatched runs on non-tag branches; you may want to make `release_tag` required for `workflow_dispatch` or derive the tag more defensively for that case.
- All updated GitHub Actions are pinned to version tags (e.g., `actions/checkout@v7.0.1`); for better supply-chain safety you might consider pinning to immutable commit SHAs instead of semver tags, especially for security-sensitive workflows like release and WinGet publishing.

## Individual Comments

### Comment 1
<location path=".github/workflows/ci.yml" line_range="25" />
<code_context>
     steps:
       - name: Check out repository
-        uses: actions/checkout@v4
+        uses: actions/checkout@v7.0.1

       - name: Install Rust toolchain
</code_context>
<issue_to_address>
**issue (bug_risk):** actions/checkout@v7.0.1 does not currently exist and will fail at runtime

The latest published major version of `actions/checkout` is `v4`. Using `actions/checkout@v7.0.1` will fail because that tag does not exist. If you want to stay current, pin to `v4` (optionally with a specific minor/patch) until a `v7` release actually appears.
</issue_to_address>

Fix all in Cursor


Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Comment thread .github/workflows/ci.yml Outdated
@qodo-code-review

qodo-code-review Bot commented Jul 29, 2026 •

Copy link
Copy Markdown
Contributor

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

Context used
✅ Compliance rules (platform): 22 rules


🟡 Remediation Recommended

1. SemVer tag regex wrong ✓ Resolved 🐞 Bug ≡ Correctness ⭐ New
Description
The new "Verify release tag shape" check accepts non‑SemVer tags like v1.2.3.4 and rejects valid
SemVer tags with build metadata like v1.2.3+build, despite the workflow/docs claiming a SemVer
v*.*.* contract. This can cause WinGet automation to proceed on invalid version tags or fail
closed on tags that still trigger the Release workflow, requiring manual recovery.
Code

.github/workflows/winget.yml[R48-50]

+          if [[ ! "$RELEASE_TAG" =~ ^v[0-9]+\.[0-9]+\.[0-9]+([.-].+)?$ ]]; then
+            echo "::error::RELEASE_TAG must be a v-prefixed SemVer tag (got: ${RELEASE_TAG:-<empty>})"
+            exit 1
Relevance

●●● Strong

Team has recently accepted workflow correctness/gating fixes in release automation; SemVer regex
tightening is low-risk.

PR-#13

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The WinGet workflow claims a v-prefixed SemVer tag contract but validates tags with a permissive
([.-].+)? suffix (allowing a fourth dot component) and no support for SemVer +build metadata.
The Release workflow’s tag trigger is a loose v*.*.* glob, so tags that can start Release may
later be rejected (or insufficiently constrained) by WinGet.

.github/workflows/winget.yml[3-6]
.github/workflows/winget.yml[44-51]
.github/workflows/release.yml[3-7]
docs/PACKAGING.md[7-11]
docs/RELEASING.md[49-53]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`winget.yml` validates `RELEASE_TAG` with `^v[0-9]+\.[0-9]+\.[0-9]+([.-].+)?$`, which:
- **accepts invalid SemVer** like `v1.2.3.4` (suffix may start with `.`)
- **rejects valid SemVer** like `v1.2.3+build` (no `+` support)
This conflicts with the documented “v-prefixed SemVer” tag contract and can break WinGet automation for some tags.

### Issue Context
The `Release` workflow is triggered by the glob `v*.*.*`, which can include tags containing `+...` or extra dot segments, so tags that start the Release workflow can later be rejected (or insufficiently validated) by the WinGet workflow.

### Fix Focus Areas
- .github/workflows/winget.yml[44-51]

### Suggested fix
Replace the regex with a SemVer-compliant pattern that:
- requires exactly `v<major>.<minor>.<patch>`
- optionally allows prerelease (`-...`) and build metadata (`+...`)
- avoids allowing an extra `.` segment after patch

Example (Bash regex) you can adapt:
```
^v(0|[1-9][0-9]*)\.(0|[1-9][0-9]*)\.(0|[1-9][0-9]*)(-[0-9A-Za-z-]+(\.[0-9A-Za-z-]+)*)?(\+[0-9A-Za-z-]+(\.[0-9A-Za-z-]+)*)?$
```
If you intentionally want to *disallow* prerelease/build metadata, then make that explicit in the comment/docs and use a strict `^v\d+\.\d+\.\d+$` instead.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. Hard-coded release job name ✓ Resolved 🐞 Bug ⚙ Maintainability
Description
The WinGet workflow’s “Verify originating release job” step keys off the Release job’s human-facing
display name ("Publish GitHub Release"), so a harmless rename of that job will make the gate fail
and block automatic WinGet submissions. This coupling is avoidable because the workflow already
verifies the existence of a non-draft release and its Windows asset, which implicitly proves the
Release publishing work succeeded.
Code

.github/workflows/winget.yml[R46-48]

+          gh api "repos/${GITHUB_REPOSITORY}/actions/runs/${RELEASE_RUN_ID}/jobs?per_page=100" \
+            --jq 'any(.jobs[]; .name == "Publish GitHub Release" and .conclusion == "success")' \
+            | grep -Fx true
Relevance

●●● Strong

Team tends to accept workflow hardening and reducing fragile string coupling; similar robustness
fixes were accepted.

PR-#13
PR-#9

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The WinGet workflow explicitly filters the Release run’s jobs by a hard-coded `.name == "Publish
GitHub Release"`, while the Release workflow shows that string is just the job’s display name for
job id release, making it easy to break by renaming the job without changing its function.

.github/workflows/winget.yml[38-48]
.github/workflows/release.yml[164-166]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`.github/workflows/winget.yml` verifies the originating Release run by querying jobs and matching the **display name** `"Publish GitHub Release"`. Display names are not stable identifiers and can be changed without changing behavior, which would silently break WinGet automation.

## Issue Context
The Release workflow defines a job with YAML id `release` but display name `Publish GitHub Release`. The WinGet workflow matches only the display name from the jobs API response, creating an unnecessary brittle dependency between two workflows.

## Fix Focus Areas
- .github/workflows/winget.yml[38-48]

## Suggested fix
Prefer a validation that doesn’t depend on a mutable job display name. The simplest fix is to **remove** the “Verify originating release job” step and rely on the subsequent “Verify published Windows release asset” check (non-draft release + expected asset) as the gate, since it already validates the essential postcondition needed for WinGet submission.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


3. Winget blocked by crate failure ✓ Resolved 🐞 Bug ☼ Reliability
Description
The WinGet workflow only runs when the entire "Release" workflow concludes with success, so a
failure in a later/independent job (notably publish-crate) will prevent WinGet submission even if
the GitHub Release and Windows .zip asset were already created successfully. This can cause missed
automatic WinGet updates and require manual dispatch more often than intended.
Code

.github/workflows/winget.yml[R20-25]

+    if: >-
+      github.event_name == 'workflow_dispatch' ||
+      (github.event.workflow_run.conclusion == 'success' &&
+      github.event.workflow_run.event == 'push' &&
+      github.event.workflow_run.head_repository.full_name == github.repository &&
+      startsWith(github.event.workflow_run.head_branch, 'v'))
Relevance

●●● Strong

Team has accepted similar release/workflow reliability gating fixes; this prevents flaky/missed
automation due to unrelated job failures.

PR-#13

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The WinGet job explicitly requires the triggering Release workflow to have an overall conclusion of
success. In the Release workflow, the GitHub Release is created in the release job, and
publish-crate runs afterward and can fail independently; that independent failure changes the
workflow’s overall conclusion to failure, preventing WinGet even though the release artifacts
already exist.

.github/workflows/winget.yml[17-35]
.github/workflows/release.yml[162-211]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`Publish to WinGet` is gated on `github.event.workflow_run.conclusion == 'success'`, which represents the *entire* Release workflow result. Because `Release` contains jobs that can fail after the GitHub Release is created (e.g., `publish-crate`), WinGet submission can be skipped even though the release assets needed for WinGet already exist.

## Issue Context
- This is a behavioral change introduced by switching from `release.published` to `workflow_run`.
- The Release workflow creates the GitHub Release before running `publish-crate`.

## Fix Focus Areas
- .github/workflows/winget.yml[20-35]

## Suggested fix approach
Implement a gate that reflects “release artifacts exist” rather than “entire workflow succeeded”, for example:
1. Keep the existing repository/event/tag safety checks.
2. Instead of requiring `workflow_run.conclusion == 'success'`, add a lightweight verification step before invoking `winget-releaser`:
  - Use `gh api` (or curl) to fetch the GitHub Release by tag (`github.event.workflow_run.head_branch`) and verify:
    - release exists,
    - it is not a draft,
    - it contains the expected Windows `.zip` asset.
  - Only then run `winget-releaser`.

This preserves “fail closed when artifacts aren’t available” while allowing WinGet submission when the release job succeeded but a later job failed.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



ℹ️ Informational

4. Dated roadmap link ✓ Resolved 🐞 Bug ⚙ Maintainability
Description
README describes the roadmap link as the “current cross-repository plan” but points to a
date-stamped snapshot file, so the README can become misleading the next time a new roadmap snapshot
is added without updating this link. This introduces avoidable maintenance churn for keeping README
accurate.
Code

README.md[R412-414]

+For the current cross-repository plan across `numan`, `numan-registry`, and
+`numan-plugins`, see
+[docs/plans/2026-07-29-remaining-roadmap.md](docs/plans/2026-07-29-remaining-roadmap.md).
Relevance

●●● Strong

Team previously accepted README/doc tweaks to avoid misleading “current” release info; likely
accepts stable/accurate roadmap link wording.

PR-#60

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
README labels the link as the current plan, but the target document declares itself as a dated
snapshot via its “Status date”, so the README link can easily become outdated without a stable
entrypoint or snapshot wording.

README.md[412-414]
docs/plans/2026-07-29-remaining-roadmap.md[1-4]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`README.md` links to a date-stamped roadmap snapshot while labeling it as the *current* plan. This will eventually become stale unless README is updated on every roadmap refresh.

### Issue Context
The linked plan document is explicitly a snapshot (it includes a `Status date`).

### Fix Focus Areas
- README.md[412-414]
- docs/plans/2026-07-29-remaining-roadmap.md[1-4]

### Suggested fix
Choose one:
1) Create a stable entrypoint file (e.g. `docs/plans/remaining-roadmap.md`) that always points to / contains the latest roadmap, and update README to link to it.
2) Keep the dated filename but update README text to explicitly call it a snapshot (e.g. “current roadmap snapshot as of 2026-07-29”), so it doesn’t promise evergreen freshness.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


5. Implicit gh/jq dependency ✓ Resolved 🐞 Bug ☼ Reliability
Description
The new WinGet “Verify published Windows release asset” step relies on gh and jq being present
on the runner image, but the workflow doesn’t install or verify those tools, so a runner-image
change could break automated WinGet submission with a command not found failure.
Code

.github/workflows/winget.yml[R36-41]

+          set -euo pipefail
+          expected_asset="numan-${RELEASE_TAG#v}-x86_64-pc-windows-msvc.zip"
+          gh release view "$RELEASE_TAG" --repo "$GITHUB_REPOSITORY" --json isDraft,assets \
+            | jq -e --arg expected_asset "$expected_asset" \
+              '.isDraft == false and any(.assets[]; .name == $expected_asset and .state == "uploaded")' \
+              >/dev/null
Relevance

●●● Strong

Team tends to accept workflow hardening to prevent flakiness; explicit tool install/verification
likely welcomed.

PR-#13

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The added step invokes gh release view and jq -e, and there is no preceding step in this job
that installs or verifies those executables.

.github/workflows/winget.yml[31-41]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The WinGet workflow added a verification step that calls `gh` and pipes to `jq`, but it does not install or verify these tools. This introduces an implicit dependency on the GitHub-hosted runner image.

### Issue Context
Today this usually works on `ubuntu-latest`, but it’s not guaranteed long-term and can fail unexpectedly if the runner image changes.

### Fix Focus Areas
- .github/workflows/winget.yml[31-42]

### Suggested fix
Add an explicit tool check/install before using them, e.g.:
- Add a small preflight step: `command -v gh && command -v jq` with a clear error message.
- And/or install `jq` explicitly (and `gh` if you want full self-containment) before the verification step.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



To customize comments, go to the Qodo configuration screen, or learn more in the docs.

Previous review results

Review updated until commit 9a60847

Results up to commit 2d5544e ⚖️ Balanced


🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)



🟡 Remediation Recommended

1. Winget blocked by crate failure ✓ Resolved 🐞 Bug ☼ Reliability
Description
The WinGet workflow only runs when the entire "Release" workflow concludes with success, so a
failure in a later/independent job (notably publish-crate) will prevent WinGet submission even if
the GitHub Release and Windows .zip asset were already created successfully. This can cause missed
automatic WinGet updates and require manual dispatch more often than intended.
Code

.github/workflows/winget.yml[R20-25]

+    if: >-
+      github.event_name == 'workflow_dispatch' ||
+      (github.event.workflow_run.conclusion == 'success' &&
+      github.event.workflow_run.event == 'push' &&
+      github.event.workflow_run.head_repository.full_name == github.repository &&
+      startsWith(github.event.workflow_run.head_branch, 'v'))
Relevance

●●● Strong

Team has accepted similar release/workflow reliability gating fixes; this prevents flaky/missed
automation due to unrelated job failures.

PR-#13

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The WinGet job explicitly requires the triggering Release workflow to have an overall conclusion of
success. In the Release workflow, the GitHub Release is created in the release job, and
publish-crate runs afterward and can fail independently; that independent failure changes the
workflow’s overall conclusion to failure, preventing WinGet even though the release artifacts
already exist.

.github/workflows/winget.yml[17-35]
.github/workflows/release.yml[162-211]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`Publish to WinGet` is gated on `github.event.workflow_run.conclusion == 'success'`, which represents the *entire* Release workflow result. Because `Release` contains jobs that can fail after the GitHub Release is created (e.g., `publish-crate`), WinGet submission can be skipped even though the release assets needed for WinGet already exist.

## Issue Context
- This is a behavioral change introduced by switching from `release.published` to `workflow_run`.
- The Release workflow creates the GitHub Release before running `publish-crate`.

## Fix Focus Areas
- .github/workflows/winget.yml[20-35]

## Suggested fix approach
Implement a gate that reflects “release artifacts exist” rather than “entire workflow succeeded”, for example:
1. Keep the existing repository/event/tag safety checks.
2. Instead of requiring `workflow_run.conclusion == 'success'`, add a lightweight verification step before invoking `winget-releaser`:
  - Use `gh api` (or curl) to fetch the GitHub Release by tag (`github.event.workflow_run.head_branch`) and verify:
    - release exists,
    - it is not a draft,
    - it contains the expected Windows `.zip` asset.
  - Only then run `winget-releaser`.

This preserves “fail closed when artifacts aren’t available” while allowing WinGet submission when the release job succeeded but a later job failed.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Results up to commit 048a989 ⚖️ Balanced


🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)



ℹ️ Informational

1. Implicit gh/jq dependency ✓ Resolved 🐞 Bug ☼ Reliability
Description
The new WinGet “Verify published Windows release asset” step relies on gh and jq being present
on the runner image, but the workflow doesn’t install or verify those tools, so a runner-image
change could break automated WinGet submission with a command not found failure.
Code

.github/workflows/winget.yml[R36-41]

+          set -euo pipefail
+          expected_asset="numan-${RELEASE_TAG#v}-x86_64-pc-windows-msvc.zip"
+          gh release view "$RELEASE_TAG" --repo "$GITHUB_REPOSITORY" --json isDraft,assets \
+            | jq -e --arg expected_asset "$expected_asset" \
+              '.isDraft == false and any(.assets[]; .name == $expected_asset and .state == "uploaded")' \
+              >/dev/null
Relevance

●●● Strong

Team tends to accept workflow hardening to prevent flakiness; explicit tool install/verification
likely welcomed.

PR-#13

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The added step invokes gh release view and jq -e, and there is no preceding step in this job
that installs or verifies those executables.

.github/workflows/winget.yml[31-41]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The WinGet workflow added a verification step that calls `gh` and pipes to `jq`, but it does not install or verify these tools. This introduces an implicit dependency on the GitHub-hosted runner image.

### Issue Context
Today this usually works on `ubuntu-latest`, but it’s not guaranteed long-term and can fail unexpectedly if the runner image changes.

### Fix Focus Areas
- .github/workflows/winget.yml[31-42]

### Suggested fix
Add an explicit tool check/install before using them, e.g.:
- Add a small preflight step: `command -v gh && command -v jq` with a clear error message.
- And/or install `jq` explicitly (and `gh` if you want full self-containment) before the verification step.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Results up to commit 4c2724a ⚖️ Balanced


🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)



🟡 Remediation Recommended

1. Hard-coded release job name ✓ Resolved 🐞 Bug ⚙ Maintainability
Description
The WinGet workflow’s “Verify originating release job” step keys off the Release job’s human-facing
display name ("Publish GitHub Release"), so a harmless rename of that job will make the gate fail
and block automatic WinGet submissions. This coupling is avoidable because the workflow already
verifies the existence of a non-draft release and its Windows asset, which implicitly proves the
Release publishing work succeeded.
Code

.github/workflows/winget.yml[R46-48]

+          gh api "repos/${GITHUB_REPOSITORY}/actions/runs/${RELEASE_RUN_ID}/jobs?per_page=100" \
+            --jq 'any(.jobs[]; .name == "Publish GitHub Release" and .conclusion == "success")' \
+            | grep -Fx true
Relevance

●●● Strong

Team tends to accept workflow hardening and reducing fragile string coupling; similar robustness
fixes were accepted.

PR-#13
PR-#9

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The WinGet workflow explicitly filters the Release run’s jobs by a hard-coded `.name == "Publish
GitHub Release"`, while the Release workflow shows that string is just the job’s display name for
job id release, making it easy to break by renaming the job without changing its function.

.github/workflows/winget.yml[38-48]
.github/workflows/release.yml[164-166]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`.github/workflows/winget.yml` verifies the originating Release run by querying jobs and matching the **display name** `"Publish GitHub Release"`. Display names are not stable identifiers and can be changed without changing behavior, which would silently break WinGet automation.

## Issue Context
The Release workflow defines a job with YAML id `release` but display name `Publish GitHub Release`. The WinGet workflow matches only the display name from the jobs API response, creating an unnecessary brittle dependency between two workflows.

## Fix Focus Areas
- .github/workflows/winget.yml[38-48]

## Suggested fix
Prefer a validation that doesn’t depend on a mutable job display name. The simplest fix is to **remove** the “Verify originating release job” step and rely on the subsequent “Verify published Windows release asset” check (non-draft release + expected asset) as the gate, since it already validates the essential postcondition needed for WinGet submission.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Results up to commit 836fea3 ⚖️ Balanced


🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)



ℹ️ Informational

1. Dated roadmap link ✓ Resolved 🐞 Bug ⚙ Maintainability
Description
README describes the roadmap link as the “current cross-repository plan” but points to a
date-stamped snapshot file, so the README can become misleading the next time a new roadmap snapshot
is added without updating this link. This introduces avoidable maintenance churn for keeping README
accurate.
Code

README.md[R412-414]

+For the current cross-repository plan across `numan`, `numan-registry`, and
+`numan-plugins`, see
+[docs/plans/2026-07-29-remaining-roadmap.md](docs/plans/2026-07-29-remaining-roadmap.md).
Relevance

●●● Strong

Team previously accepted README/doc tweaks to avoid misleading “current” release info; likely
accepts stable/accurate roadmap link wording.

PR-#60

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
README labels the link as the current plan, but the target document declares itself as a dated
snapshot via its “Status date”, so the README link can easily become outdated without a stable
entrypoint or snapshot wording.

README.md[412-414]
docs/plans/2026-07-29-remaining-roadmap.md[1-4]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`README.md` links to a date-stamped roadmap snapshot while labeling it as the *current* plan. This will eventually become stale unless README is updated on every roadmap refresh.

### Issue Context
The linked plan document is explicitly a snapshot (it includes a `Status date`).

### Fix Focus Areas
- README.md[412-414]
- docs/plans/2026-07-29-remaining-roadmap.md[1-4]

### Suggested fix
Choose one:
1) Create a stable entrypoint file (e.g. `docs/plans/remaining-roadmap.md`) that always points to / contains the latest roadmap, and update README to link to it.
2) Keep the dated filename but update README text to explicitly call it a snapshot (e.g. “current roadmap snapshot as of 2026-07-29”), so it doesn’t promise evergreen freshness.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Powered by Qodo

Comment thread .github/workflows/winget.yml
@qodo-code-review

Copy link
Copy Markdown
Contributor

Qodo Fixer

✅ Merged (0) · ☑ Fixed (0)

Process

  • No fixes were applied (no_fixes_applied)

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/active-plugin-update-acceptance.yml:
- Around line 21-27: Replace every movable-tag uses reference with the
corresponding full immutable commit SHA across all listed workflow sites:
.github/workflows/active-plugin-update-acceptance.yml lines 21-27;
.github/workflows/ci.yml lines 25-27, 35-39, 46, 56-58, 65-67, 74, and 84-86;
.github/workflows/official-registry-acceptance.yml lines 17-23;
.github/workflows/claude-code-review.yml line 19; .github/workflows/claude.yml
line 29; .github/workflows/cline-pr-review.yml line 31; and
.github/workflows/release.yml lines 55-58, 69-73, 105, 124, 156, 167, 179, and
208. Preserve each action and its current version while pinning it to the
verified commit SHA.

In @.github/workflows/ci.yml:
- Line 27: Update each Swatinem/rust-cache step in the CI workflow to prevent
fork- or pull-request-controlled jobs from writing or restoring caches used by
trusted workflows. Gate cache usage or writes on trusted refs/conditions, while
preserving caching for trusted runs across all referenced jobs.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: e3999413-ef91-4223-907f-7e88aae31e65

📥 Commits

Reviewing files that changed from the base of the PR and between 1275b0a and 2d5544e.

📒 Files selected for processing (10)
  • .github/workflows/active-plugin-update-acceptance.yml
  • .github/workflows/ci.yml
  • .github/workflows/claude-code-review.yml
  • .github/workflows/claude.yml
  • .github/workflows/cline-pr-review.yml
  • .github/workflows/official-registry-acceptance.yml
  • .github/workflows/release.yml
  • .github/workflows/winget.yml
  • docs/PACKAGING.md
  • docs/RELEASING.md
🔗 Linked repositories identified

CodeRabbit considers these linked repositories for cross-repo context during reviews:

  • Trackdubllc/Trackdub (manual)
  • tonythethompson/QuickShell (manual)
  • tonythethompson/numan (manual)
  • tonythethompson/dependency-chain-substrate (manual)
📜 Review details
⏰ Context from checks skipped due to timeout. (4)
  • GitHub Check: Sourcery review
  • GitHub Check: Test (windows-latest)
  • GitHub Check: Real-Nu acceptance (windows-latest)
  • GitHub Check: Analyze (rust)
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{rs,md}

📄 CodeRabbit inference engine (CONTRIBUTING.md)

Update documentation when changing structure, conventions, or user-visible behavior, using AGENTS.md, docs/, or command help as appropriate.

Files:

  • docs/RELEASING.md
  • docs/PACKAGING.md
**/*

📄 CodeRabbit inference engine (CONTRIBUTING.md)

Redact secrets when reporting relevant logs or lockfile excerpts in issues.

Files:

  • docs/RELEASING.md
  • docs/PACKAGING.md
🪛 LanguageTool
docs/RELEASING.md

[style] ~52-~52: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...CRATES_IO_TOKEN repository secret). 9. Confirm the [Publish to WinGet`](../.github/wo...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[uncategorized] ~52-~52: The official name of this software platform is spelled with a capital “H”.
Context: ...KEN repository secret). 9. Confirm the [Publish to WinGet`](../.github/workflows/winget.yml) workflow opens th...

(GITHUB)

docs/PACKAGING.md

[uncategorized] ~10-~10: The official name of this software platform is spelled with a capital “H”.
Context: ...riggered Release workflow succeeds, the Publish to WinGet workflow generate...

(GITHUB)

🪛 zizmor (1.28.0)
.github/workflows/claude.yml

[error] 29-29: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)

.github/workflows/active-plugin-update-acceptance.yml

[error] 21-21: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 24-24: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 27-27: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[info] 24-24: action functionality is already included by the runner (superfluous-actions): use rustup and/or cargo in a script step

(superfluous-actions)

.github/workflows/cline-pr-review.yml

[error] 31-31: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)

.github/workflows/official-registry-acceptance.yml

[error] 17-17: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 20-20: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 23-23: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[info] 20-20: action functionality is already included by the runner (superfluous-actions): use rustup and/or cargo in a script step

(superfluous-actions)

.github/workflows/claude-code-review.yml

[error] 19-19: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)

.github/workflows/release.yml

[error] 55-55: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[warning] 69-69: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)


[error] 69-69: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 70-70: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 73-73: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 73-73: runtime artifacts potentially vulnerable to a cache poisoning attack (cache-poisoning): enables caching by default

(cache-poisoning)


[info] 70-70: action functionality is already included by the runner (superfluous-actions): use rustup and/or cargo in a script step

(superfluous-actions)


[warning] 105-105: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)


[error] 105-105: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 124-124: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 124-124: runtime artifacts potentially vulnerable to a cache poisoning attack (cache-poisoning): enables caching by default

(cache-poisoning)


[error] 156-156: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[warning] 167-167: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)


[error] 167-167: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 179-179: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[warning] 208-208: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)


[error] 208-208: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)

.github/workflows/ci.yml

[warning] 25-25: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)


[warning] 35-35: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)


[warning] 46-46: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)


[error] 25-25: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 26-26: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 27-27: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 35-35: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 36-36: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 39-39: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 46-46: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 27-27: runtime artifacts potentially vulnerable to a cache poisoning attack (cache-poisoning): enables caching by default

(cache-poisoning)


[error] 39-39: runtime artifacts potentially vulnerable to a cache poisoning attack (cache-poisoning): enables caching by default

(cache-poisoning)


[info] 26-26: action functionality is already included by the runner (superfluous-actions): use rustup and/or cargo in a script step

(superfluous-actions)


[info] 36-36: action functionality is already included by the runner (superfluous-actions): use rustup and/or cargo in a script step

(superfluous-actions)


[warning] 56-56: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)


[warning] 65-65: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)


[warning] 74-74: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)


[error] 56-56: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 57-57: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 58-58: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 65-65: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 66-66: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 67-67: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 74-74: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 58-58: runtime artifacts potentially vulnerable to a cache poisoning attack (cache-poisoning): enables caching by default

(cache-poisoning)


[error] 67-67: runtime artifacts potentially vulnerable to a cache poisoning attack (cache-poisoning): enables caching by default

(cache-poisoning)


[info] 57-57: action functionality is already included by the runner (superfluous-actions): use rustup and/or cargo in a script step

(superfluous-actions)


[info] 66-66: action functionality is already included by the runner (superfluous-actions): use rustup and/or cargo in a script step

(superfluous-actions)


[warning] 84-84: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)


[error] 84-84: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 85-85: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 86-86: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 86-86: runtime artifacts potentially vulnerable to a cache poisoning attack (cache-poisoning): enables caching by default

(cache-poisoning)


[info] 85-85: action functionality is already included by the runner (superfluous-actions): use rustup and/or cargo in a script step

(superfluous-actions)

🔍 Remote MCP GitHub Copilot

Relevant review context

  • lewagon/wait-on-check-action only requires ref and repo-token; its action.yml has no repo input, so removing that input matches upstream docs. Its README also points to workflow_run as the native alternative for default-branch-only workflows.
  • The PR’s pinned action versions match current upstream releases: actions/checkout v7.0.1, Swatinem/rust-cache v2.9.1, lewagon/wait-on-check-action v1.9.0, actions/upload-artifact v7.0.1, and actions/download-artifact v8.0.1.
  • actions/checkout v7 adds safer fork PR handling via allow-unsafe-pr-checkout, plus ESM/dependency updates.
🔇 Additional comments (4)
.github/workflows/claude-code-review.yml (1)

33-33: LGTM!

.github/workflows/winget.yml (1)

20-25: 🗄️ Data Integrity & Integration

Prove that the triggering ref is a tag, not merely v-prefixed.

This guard accepts any successful push run whose head_branch starts with v. If the Release workflow can run for a branch named v..., WinGet publication will proceed from a non-tag run, violating the stated boundary. Make the Release trigger tag-only or validate that the triggering head_sha is actually referenced by refs/tags/v... before invoking winget-releaser. GitHub exposes the triggering workflow-run payload to downstream workflow_run workflows, so this validation should be explicit rather than inferred from a prefix. (docs.github.com)

docs/PACKAGING.md (1)

10-10: LGTM!

docs/RELEASING.md (1)

52-52: LGTM!

Comment thread .github/workflows/active-plugin-update-acceptance.yml Outdated
Comment thread .github/workflows/ci.yml Outdated
@qodo-code-review

Copy link
Copy Markdown
Contributor

Code review by qodo was updated up to the latest commit feb21b4

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/ci.yml:
- Line 26: Replace every dtolnay/rust-toolchain reference at
.github/workflows/ci.yml lines 26-26, 36-36, 57-57, 66-66, and 85-85,
.github/workflows/official-registry-acceptance.yml line 20-20, and
.github/workflows/release.yml line 70-70 with the full commit SHA for its
existing Rust channel, preserving whether each reference uses stable or 1.88.

In @.github/workflows/cline-pr-review.yml:
- Line 31: Update the actions/setup-node step in the workflow to use
actions/setup-node@v5 and pin it to the corresponding commit SHA, completing the
job’s Node 24 migration while preserving the existing setup configuration.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: b1882797-ca59-4010-bac0-e589f050e0db

📥 Commits

Reviewing files that changed from the base of the PR and between 2d5544e and feb21b4.

📒 Files selected for processing (7)
  • .github/workflows/active-plugin-update-acceptance.yml
  • .github/workflows/ci.yml
  • .github/workflows/claude-code-review.yml
  • .github/workflows/claude.yml
  • .github/workflows/cline-pr-review.yml
  • .github/workflows/official-registry-acceptance.yml
  • .github/workflows/release.yml
🔗 Linked repositories identified

CodeRabbit considers these linked repositories for cross-repo context during reviews:

  • Trackdubllc/Trackdub (manual)
  • tonythethompson/QuickShell (manual)
  • tonythethompson/numan (manual)
  • tonythethompson/dependency-chain-substrate (manual)
📜 Review details
⏰ Context from checks skipped due to timeout. (3)
  • GitHub Check: Real-Nu acceptance (windows-latest)
  • GitHub Check: Test (windows-latest)
  • GitHub Check: Analyze (rust)
🧰 Additional context used
🪛 zizmor (1.28.0)
.github/workflows/official-registry-acceptance.yml

[error] 20-20: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[info] 20-20: action functionality is already included by the runner (superfluous-actions): use rustup and/or cargo in a script step

(superfluous-actions)

.github/workflows/active-plugin-update-acceptance.yml

[error] 24-24: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[info] 24-24: action functionality is already included by the runner (superfluous-actions): use rustup and/or cargo in a script step

(superfluous-actions)

.github/workflows/ci.yml

[warning] 25-25: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)


[warning] 35-35: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)


[warning] 46-46: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)


[error] 26-26: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 36-36: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 27-27: runtime artifacts potentially vulnerable to a cache poisoning attack (cache-poisoning): enables caching by default

(cache-poisoning)


[error] 39-39: runtime artifacts potentially vulnerable to a cache poisoning attack (cache-poisoning): enables caching by default

(cache-poisoning)


[info] 26-26: action functionality is already included by the runner (superfluous-actions): use rustup and/or cargo in a script step

(superfluous-actions)


[info] 36-36: action functionality is already included by the runner (superfluous-actions): use rustup and/or cargo in a script step

(superfluous-actions)


[warning] 56-56: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)


[warning] 65-65: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)


[warning] 74-74: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)


[error] 57-57: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 66-66: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 58-58: runtime artifacts potentially vulnerable to a cache poisoning attack (cache-poisoning): enables caching by default

(cache-poisoning)


[error] 67-67: runtime artifacts potentially vulnerable to a cache poisoning attack (cache-poisoning): enables caching by default

(cache-poisoning)


[info] 57-57: action functionality is already included by the runner (superfluous-actions): use rustup and/or cargo in a script step

(superfluous-actions)


[info] 66-66: action functionality is already included by the runner (superfluous-actions): use rustup and/or cargo in a script step

(superfluous-actions)


[warning] 84-84: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)


[error] 85-85: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 86-86: runtime artifacts potentially vulnerable to a cache poisoning attack (cache-poisoning): enables caching by default

(cache-poisoning)


[info] 85-85: action functionality is already included by the runner (superfluous-actions): use rustup and/or cargo in a script step

(superfluous-actions)

.github/workflows/release.yml

[warning] 69-69: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)


[error] 70-70: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 73-73: runtime artifacts potentially vulnerable to a cache poisoning attack (cache-poisoning): enables caching by default

(cache-poisoning)


[info] 70-70: action functionality is already included by the runner (superfluous-actions): use rustup and/or cargo in a script step

(superfluous-actions)


[warning] 105-105: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)


[error] 124-124: runtime artifacts potentially vulnerable to a cache poisoning attack (cache-poisoning): enables caching by default

(cache-poisoning)


[warning] 167-167: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)


[warning] 208-208: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)

🔍 Remote MCP DeepWiki, GitHub Copilot

Relevant review context

  • The current repository’s Release workflow is triggered by semantic-version tag pushes (v*.*.*) and manual dispatch. Its release job creates the GitHub Release and attaches platform archives plus SHA256SUMS; the Windows artifact is a .zip.
  • The current Publish to WinGet workflow still uses release: published and derives release-tag from github.event.release.tag_name when not manually dispatched. This confirms the PR is changing the existing release-to-WinGet handoff rather than introducing a new packaging path.
  • Repository documentation states that WinGet automation uses the Windows .zip, the WINGET_TOKEN secret, and the existing tonythethompson/winget-pkgs fork.
  • DeepWiki’s indexed release documentation is stale relative to the checked repository files: it claims WinGet publishing is manual and lists no automated workflow. Review the PR’s actual workflow diff and current GitHub Actions behavior rather than relying on that architectural summary.
  • The repository’s release pipeline has explicit CI gating before building and publishing release artifacts, so the new workflow_run condition should preserve the intended dependency on a successful tag-based Release run.
🔀 Multi-repo context tonythethompson/QuickShell, Trackdubllc/Trackdub, tonythethompson/dependency-chain-substrate

Linked repositories findings

tonythethompson/QuickShell

  • QuickShell documents that releases created with GITHUB_TOKEN do not trigger downstream workflows, so it explicitly dispatches Store publishing from the release workflow using gh workflow run. This supports the PR’s rationale for avoiding release-event recursion suppression. [::tonythethompson/QuickShell::] .github/workflows/release-extension.yml:205-245, docs/release-packages.md:13-16
  • Its release workflow accepts v* tag pushes and manual dispatch, matching the PR’s tag-based/manual recovery model. [::tonythethompson/QuickShell::] .github/workflows/release-extension.yml:3-22
  • QuickShell’s WinGet automation runs as a dependent job after a successful build and uses a PAT (WINGET_PAT) for manifest submission. This is a different secret and submission model from the PR’s WINGET_TOKEN/fork-based flow; no shared contract was found. [::tonythethompson/QuickShell::] .github/workflows/release-extension.yml:236-245, :291-320
  • QuickShell still uses actions/checkout@v4 in its release workflow, so it provides no evidence that the PR’s checkout@v7.0.1 pin is required by a linked consumer. [::tonythethompson/QuickShell::] .github/workflows/release-extension.yml:47-50, :248-252

Trackdubllc/Trackdub

  • Trackdub uses actions/checkout@v7 and actions/upload-artifact@v7 in CI, showing compatible action-major usage in another linked repository, but its references are tags rather than the PR’s commit pins. [::Trackdubllc/Trackdub::] .github/workflows/ci.yml:24-25, .github/workflows/code-coverage.yml:95-100
  • No WinGet publishing workflow, workflow_run, wait-on-check-action, or WINGET_TOKEN reference was found.

tonythethompson/dependency-chain-substrate

  • Its release workflow is independently triggered by v* tags or manual dispatch and validates that the requested/tagged version matches the project version before publishing. This is consistent with the PR’s tag-oriented release model, but it has no WinGet or downstream workflow_run consumer. [::tonythethompson/dependency-chain-substrate::] .github/workflows/release.yml:3-16, :24-43
  • No WinGet publishing workflow, workflow_run, or wait-on-check-action reference was found.
🔇 Additional comments (7)
.github/workflows/active-plugin-update-acceptance.yml (2)

24-24: 🔒 Security & Privacy

Security Misconfiguration (CWE-829): Inclusion of Functionality from Untrusted Control Sphere

Reachability: External

The existing mutable Rust-toolchain action finding remains unresolved.

Line 24 still uses the movable stable tag. Pin the action implementation to a verified full commit SHA, as requested in the prior review.

Source: Linters/SAST tools


21-21: LGTM!

Also applies to: 27-27, 51-51

.github/workflows/ci.yml (1)

25-25: LGTM!

Also applies to: 35-35, 46-46, 56-56, 65-65, 74-74, 84-84

.github/workflows/official-registry-acceptance.yml (1)

17-17: LGTM!

Also applies to: 23-23, 48-48

.github/workflows/claude-code-review.yml (1)

19-19: LGTM!

Also applies to: 33-33

.github/workflows/claude.yml (1)

29-29: LGTM!

.github/workflows/release.yml (1)

55-61: LGTM!

Also applies to: 69-69, 71-73, 105-105, 124-124, 156-156, 167-167, 179-179, 208-208

Comment thread .github/workflows/ci.yml Outdated
Comment thread .github/workflows/cline-pr-review.yml
Comment thread .github/workflows/winget.yml
@qodo-code-review

Copy link
Copy Markdown
Contributor

Code review by qodo was updated up to the latest commit 048a989

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/winget.yml:
- Around line 22-23: Update the workflow_run conclusion condition in the WinGet
job to allow execution only when github.event.workflow_run.conclusion is
success; remove the failure alternative while preserving the surrounding event
and permission checks.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 312b00f2-02b7-432d-b60c-ca5f004b9552

📥 Commits

Reviewing files that changed from the base of the PR and between feb21b4 and 048a989.

📒 Files selected for processing (4)
  • .github/workflows/ci.yml
  • .github/workflows/winget.yml
  • docs/PACKAGING.md
  • docs/RELEASING.md
🔗 Linked repositories identified

CodeRabbit considers these linked repositories for cross-repo context during reviews:

  • Trackdubllc/Trackdub (manual)
  • tonythethompson/QuickShell (manual)
  • tonythethompson/numan (manual)
  • tonythethompson/dependency-chain-substrate (manual)
📜 Review details
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{rs,md}

📄 CodeRabbit inference engine (CONTRIBUTING.md)

Update documentation when changing structure, conventions, or user-visible behavior, using AGENTS.md, docs/, or command help as appropriate.

Files:

  • docs/RELEASING.md
  • docs/PACKAGING.md
**/*

📄 CodeRabbit inference engine (CONTRIBUTING.md)

Redact secrets when reporting relevant logs or lockfile excerpts in issues.

Files:

  • docs/RELEASING.md
  • docs/PACKAGING.md
🪛 LanguageTool
docs/RELEASING.md

[style] ~52-~52: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...CRATES_IO_TOKEN repository secret). 9. Confirm the [Publish to WinGet`](../.github/wo...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[uncategorized] ~52-~52: The official name of this software platform is spelled with a capital “H”.
Context: ...KEN repository secret). 9. Confirm the [Publish to WinGet`](../.github/workflows/winget.yml) workflow verifies...

(GITHUB)

docs/PACKAGING.md

[uncategorized] ~10-~10: The official name of this software platform is spelled with a capital “H”.
Context: ...iggered Release workflow completes, the Publish to WinGet workflow verifies...

(GITHUB)

🔍 Remote MCP Context7, DeepWiki, GitHub Copilot

Additional review context

  • GitHub documents workflow_run as suitable for chaining workflows; the downstream workflow can access secrets and write tokens. This supports the PR’s stated workaround for GITHUB_TOKEN event-recursion suppression.
  • A workflow_run job can gate execution on github.event.workflow_run.conclusion, including success or failure.
  • GitHub documents branch filters for workflow_run, but the retrieved documentation does not establish that head_branch reliably represents a pushed tag or that branch filters match tag refs. This remains an important point to verify in the actual workflow/event payload.
  • DeepWiki and GitHub repository lookups failed because mta1124-1629472/Babel-Player was not accessible/indexed, so no additional repository-specific facts were obtained.,
🔀 Multi-repo context tonythethompson/QuickShell, Trackdubllc/Trackdub, tonythethompson/dependency-chain-substrate

Linked repositories findings

tonythethompson/QuickShell

  • Release automation explicitly avoids downstream workflow suppression by dispatching publishing from the release workflow; this supports the PR’s workflow_run rationale. [::tonythethompson/QuickShell::]
  • Its WinGet flow uses a PAT and dependent release job, not the PR’s WINGET_TOKEN/fork-based contract. No shared interface was found. [::tonythethompson/QuickShell::]

Trackdubllc/Trackdub

  • CI uses actions/checkout@v7 and actions/upload-artifact@v7, providing evidence that these action majors are used in a linked repository. It does not use the PR’s commit pinning scheme. [::Trackdubllc/Trackdub::]
  • No WinGet, workflow_run, or WINGET_TOKEN references were found. [::Trackdubllc/Trackdub::]

tonythethompson/dependency-chain-substrate

  • Its release workflow supports v* tags and manual dispatch, consistent with the PR’s tag/manual recovery model. No WinGet or downstream workflow consumer was found. [::tonythethompson/dependency-chain-substrate::]
🔇 Additional comments (5)
.github/workflows/ci.yml (1)

25-29: Pin the remaining dtolnay/rust-toolchain references.

The checkout and cache actions are now pinned, but dtolnay/rust-toolchain@stable / @1.88 remain mutable in these jobs. Replace them with full commit SHAs while preserving their existing channels; this is the same unresolved supply-chain issue reported previously.

#!/bin/bash
set -euo pipefail
rg -n 'dtolnay/rust-toolchain@(stable|1\.88)' .github/workflows

Also applies to: 37-43, 60-64, 71-75, 92-96

Source: Linters/SAST tools

.github/workflows/winget.yml (2)

4-6: LGTM!

Also applies to: 31-49


24-29: 🎯 Functional Correctness

head_branch is the tag here, so this gate and RELEASE_TAG fallback are fine.

			> Likely an incorrect or invalid review comment.
docs/PACKAGING.md (1)

10-10: LGTM!

docs/RELEASING.md (1)

52-52: LGTM!

Comment thread .github/workflows/winget.yml
@qodo-code-review

Copy link
Copy Markdown
Contributor

Code review by qodo was updated up to the latest commit 5c4b408

coderabbitai[bot]
coderabbitai Bot previously approved these changes Jul 29, 2026
Comment thread .github/workflows/winget.yml Outdated
@qodo-code-review

Copy link
Copy Markdown
Contributor

Code review by qodo was updated up to the latest commit 4c2724a

Comment thread README.md Outdated
@qodo-code-review

Copy link
Copy Markdown
Contributor

Code review by qodo was updated up to the latest commit 836fea3

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/winget.yml:
- Around line 46-48: Update the WinGet release-gating check in the workflow to
stop matching the release job’s display name. Use a stable release marker or
artifact produced by the release workflow, and ensure the producer/consumer
contract remains enforced so successful releases continue to unblock WinGet even
if the job is renamed.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: ebcc4bff-f3df-4200-9499-2b8e38266130

📥 Commits

Reviewing files that changed from the base of the PR and between 048a989 and 836fea3.

📒 Files selected for processing (10)
  • .github/workflows/active-plugin-update-acceptance.yml
  • .github/workflows/ci.yml
  • .github/workflows/cline-pr-review.yml
  • .github/workflows/official-registry-acceptance.yml
  • .github/workflows/release.yml
  • .github/workflows/winget.yml
  • README.md
  • docs/PACKAGING.md
  • docs/RELEASING.md
  • docs/plans/2026-07-29-remaining-roadmap.md
🔗 Linked repositories identified

CodeRabbit considers these linked repositories for cross-repo context during reviews:

  • Trackdubllc/Trackdub (manual)
  • tonythethompson/QuickShell (manual)
  • tonythethompson/numan (manual)
  • tonythethompson/dependency-chain-substrate (manual)
📜 Review details
⏰ Context from checks skipped due to timeout. (3)
  • GitHub Check: Test (windows-latest)
  • GitHub Check: Real-Nu acceptance (windows-latest)
  • GitHub Check: Analyze (rust)
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{rs,md}

📄 CodeRabbit inference engine (CONTRIBUTING.md)

Update documentation when changing structure, conventions, or user-visible behavior, using AGENTS.md, docs/, or command help as appropriate.

Files:

  • docs/plans/2026-07-29-remaining-roadmap.md
  • README.md
  • docs/PACKAGING.md
  • docs/RELEASING.md
**/*

📄 CodeRabbit inference engine (CONTRIBUTING.md)

Redact secrets when reporting relevant logs or lockfile excerpts in issues.

Files:

  • docs/plans/2026-07-29-remaining-roadmap.md
  • README.md
  • docs/PACKAGING.md
  • docs/RELEASING.md
🪛 LanguageTool
docs/PACKAGING.md

[uncategorized] ~10-~10: The official name of this software platform is spelled with a capital “H”.
Context: ...iggered Release workflow completes, the Publish to WinGet workflow verifies...

(GITHUB)

docs/RELEASING.md

[style] ~52-~52: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...CRATES_IO_TOKEN repository secret). 9. Confirm the [Publish to WinGet`](../.github/wo...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[uncategorized] ~52-~52: The official name of this software platform is spelled with a capital “H”.
Context: ...KEN repository secret). 9. Confirm the [Publish to WinGet`](../.github/workflows/winget.yml) workflow verifies...

(GITHUB)

🪛 zizmor (1.28.0)
.github/workflows/active-plugin-update-acceptance.yml

[info] 24-24: action functionality is already included by the runner (superfluous-actions): use rustup and/or cargo in a script step

(superfluous-actions)

.github/workflows/winget.yml

[warning] 15-15: permissions without explanatory comments (undocumented-permissions): needs an explanatory comment

(undocumented-permissions)

.github/workflows/official-registry-acceptance.yml

[info] 20-20: action functionality is already included by the runner (superfluous-actions): use rustup and/or cargo in a script step

(superfluous-actions)

.github/workflows/ci.yml

[info] 26-26: action functionality is already included by the runner (superfluous-actions): use rustup and/or cargo in a script step

(superfluous-actions)


[info] 40-40: action functionality is already included by the runner (superfluous-actions): use rustup and/or cargo in a script step

(superfluous-actions)


[info] 54-54: action functionality is already included by the runner (superfluous-actions): use rustup and/or cargo in a script step

(superfluous-actions)


[info] 65-65: action functionality is already included by the runner (superfluous-actions): use rustup and/or cargo in a script step

(superfluous-actions)


[info] 78-78: action functionality is already included by the runner (superfluous-actions): use rustup and/or cargo in a script step

(superfluous-actions)


[info] 101-101: action functionality is already included by the runner (superfluous-actions): use rustup and/or cargo in a script step

(superfluous-actions)

.github/workflows/release.yml

[info] 70-70: action functionality is already included by the runner (superfluous-actions): use rustup and/or cargo in a script step

(superfluous-actions)


[info] 121-121: action functionality is already included by the runner (superfluous-actions): use rustup and/or cargo in a script step

(superfluous-actions)


[info] 211-211: action functionality is already included by the runner (superfluous-actions): use rustup and/or cargo in a script step

(superfluous-actions)

🔍 Remote MCP DeepWiki, GitHub Copilot

Relevant review context

  • PR #61 changes WinGet automation to trigger from completed Release workflow runs and gates automatic execution on a push, same repository, v* branch, and workflow conclusion success or failure. It then verifies the Publish GitHub Release job and the expected non-draft Windows ZIP asset before submission.
  • The current PR checks show Rust tests, Clippy, MSRV, formatting, packaging, and macOS acceptance passing; Windows and some CodeQL/Rust analysis checks were still in progress when retrieved.
  • A review identified remaining brittleness: winget.yml matches the mutable display name "Publish GitHub Release" rather than a stable job identifier. Renaming that job would block automation.
  • DeepWiki’s repository information appears stale: it describes WinGet publishing as manual and says no winget.yml exists, conflicting with the current PR diff. It should not be relied on for validating this workflow change.
  • The PR’s related context confirms the Release workflow creates the GitHub Release before the independent publish-crate job; therefore allowing a completed workflow with conclusion failure is intentional, provided the release-job and asset checks pass.
🔀 Multi-repo context tonythethompson/QuickShell, Trackdubllc/Trackdub, tonythethompson/dependency-chain-substrate

Linked repositories findings

tonythethompson/QuickShell

  • Release automation explicitly avoids downstream workflow suppression by dispatching publishing from the release workflow; this supports the PR’s workflow_run rationale. [::tonythethompson/QuickShell::]
  • Its WinGet flow uses a PAT and dependent release job, not the PR’s WINGET_TOKEN/fork-based contract. No shared interface was found. [::tonythethompson/QuickShell::]

Trackdubllc/Trackdub

  • CI uses actions/checkout@v7 and actions/upload-artifact@v7, providing evidence that these action majors are used in a linked repository. It does not use the PR’s commit pinning scheme. [::Trackdubllc/Trackdub::]
  • No WinGet, workflow_run, or WINGET_TOKEN references were found. [::Trackdubllc/Trackdub::]

tonythethompson/dependency-chain-substrate

  • Its release workflow supports v* tags and manual dispatch, consistent with the PR’s tag/manual recovery model. No WinGet or downstream workflow consumer was found. [::tonythethompson/dependency-chain-substrate::]
🔇 Additional comments (10)
README.md (1)

412-415: LGTM!

docs/plans/2026-07-29-remaining-roadmap.md (1)

1-134: LGTM!

.github/workflows/active-plugin-update-acceptance.yml (1)

24-29: LGTM!

Also applies to: 53-53

.github/workflows/ci.yml (1)

25-59: LGTM!

Also applies to: 60-85, 86-92, 100-106

.github/workflows/official-registry-acceptance.yml (1)

17-25: LGTM!

Also applies to: 50-50

.github/workflows/cline-pr-review.yml (1)

31-36: LGTM!

.github/workflows/release.yml (1)

55-58: LGTM!

Also applies to: 69-74, 106-126, 158-158, 169-169, 181-181, 210-213

.github/workflows/winget.yml (1)

4-6: LGTM!

Also applies to: 15-15, 21-30, 32-45, 50-69

docs/PACKAGING.md (1)

10-10: LGTM!

docs/RELEASING.md (1)

52-52: LGTM!

Comment thread .github/workflows/winget.yml Outdated
Stop matching the mutable Publish GitHub Release job display name.

Co-authored-by: Cursor <cursoragent@cursor.com>
@qodo-code-review

Copy link
Copy Markdown
Contributor

Code review by qodo was updated up to the latest commit 117c9c2

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/release.yml:
- Around line 204-208: Update the WinGet marker, tag resolver, and changelog
steps to pass steps.meta.outputs.tag through an environment variable or
equivalent shell-safe handoff, then reference that variable inside each run
script instead of interpolating the workflow expression directly. Preserve the
existing tag and artifact behavior while preventing crafted dispatch input from
being interpreted as shell syntax.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 91573732-8cd4-4298-8685-45bb6bc84928

📥 Commits

Reviewing files that changed from the base of the PR and between 836fea3 and 117c9c2.

📒 Files selected for processing (5)
  • .github/workflows/release.yml
  • .github/workflows/winget.yml
  • README.md
  • docs/PACKAGING.md
  • docs/RELEASING.md
🔗 Linked repositories identified

CodeRabbit considers these linked repositories for cross-repo context during reviews:

  • Trackdubllc/Trackdub (manual)
  • tonythethompson/QuickShell (manual)
  • tonythethompson/numan (manual)
  • tonythethompson/dependency-chain-substrate (manual)
📜 Review details
⏰ Context from checks skipped due to timeout. (4)
  • GitHub Check: Analyze (rust)
  • GitHub Check: Test (macos-latest)
  • GitHub Check: Real-Nu acceptance (windows-latest)
  • GitHub Check: Test (windows-latest)
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{rs,md}

📄 CodeRabbit inference engine (CONTRIBUTING.md)

Update documentation when changing structure, conventions, or user-visible behavior, using AGENTS.md, docs/, or command help as appropriate.

Files:

  • README.md
  • docs/PACKAGING.md
  • docs/RELEASING.md
**/*

📄 CodeRabbit inference engine (CONTRIBUTING.md)

Redact secrets when reporting relevant logs or lockfile excerpts in issues.

Files:

  • README.md
  • docs/PACKAGING.md
  • docs/RELEASING.md
🪛 LanguageTool
docs/PACKAGING.md

[uncategorized] ~10-~10: The official name of this software platform is spelled with a capital “H”.
Context: ...iggered Release workflow completes, the Publish to WinGet workflow verifies...

(GITHUB)

docs/RELEASING.md

[style] ~52-~52: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...CRATES_IO_TOKEN repository secret). 9. Confirm the [Publish to WinGet`](../.github/wo...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[uncategorized] ~52-~52: The official name of this software platform is spelled with a capital “H”.
Context: ...KEN repository secret). 9. Confirm the [Publish to WinGet`](../.github/workflows/winget.yml) workflow verifies...

(GITHUB)

🪛 zizmor (1.28.0)
.github/workflows/release.yml

[info] 208-208: code injection via template expansion (template-injection): may expand into attacker-controllable code

(template-injection)

🔀 Multi-repo context tonythethompson/QuickShell, Trackdubllc/Trackdub, tonythethompson/dependency-chain-substrate

Linked repositories findings

tonythethompson/QuickShell

  • Release automation explicitly avoids downstream workflow suppression by dispatching publishing from the release workflow; this supports the PR’s workflow_run rationale. [::tonythethompson/QuickShell::]
  • Its WinGet flow uses a PAT and dependent release job, not the PR’s WINGET_TOKEN/fork-based contract. No shared interface was found. [::tonythethompson/QuickShell::]

Trackdubllc/Trackdub

  • CI uses actions/checkout@v7 and actions/upload-artifact@v7, providing evidence that these action majors are used in a linked repository. It does not use the PR’s commit pinning scheme. [::Trackdubllc/Trackdub::]
  • No WinGet, workflow_run, or WINGET_TOKEN references were found. [::Trackdubllc/Trackdub::]

tonythethompson/dependency-chain-substrate

  • Its release workflow supports v* tags and manual dispatch, consistent with the PR’s tag/manual recovery model. No WinGet or downstream workflow consumer was found. [::tonythethompson/dependency-chain-substrate::]
🔇 Additional comments (5)
README.md (1)

412-414: LGTM!

.github/workflows/release.yml (1)

55-58: LGTM!

Also applies to: 69-74, 106-106, 121-126, 158-158, 169-169, 181-181

.github/workflows/winget.yml (1)

4-6: LGTM!

Also applies to: 15-40, 41-49, 50-62, 64-70

docs/PACKAGING.md (1)

10-10: LGTM!

docs/RELEASING.md (1)

52-52: LGTM!

Comment thread .github/workflows/release.yml Outdated
Make dispatch tag selection event-explicit and reject malformed tags.

Co-authored-by: Cursor <cursoragent@cursor.com>
Comment thread .github/workflows/winget.yml Outdated
@qodo-code-review

Copy link
Copy Markdown
Contributor

Code review by qodo was updated up to the latest commit 62b295a

tonythethompson and others added 4 commits July 30, 2026 05:04
Fold plugins, registry, and client remaining plans into one ordered
critical path, and point the prior draft at the new authority.

Co-authored-by: Cursor <cursoragent@cursor.com>
Keep the consolidated roadmap prior-draft link because that file still
exists on this branch.

Co-authored-by: Cursor <cursoragent@cursor.com>
Pass dispatch/release tags through env vars instead of expanding them
into run scripts, and tighten WinGet tag validation to real SemVer.

Co-authored-by: Cursor <cursoragent@cursor.com>
@qodo-code-review

qodo-code-review Bot commented Jul 30, 2026 •

Copy link
Copy Markdown
Contributor

Code Review by Qodo


Sorry, something went wrong

We weren't able to complete the code review on our side. Please try again manually by commenting /agentic_review on this PR.

Powered by Qodo

@tonythethompson
tonythethompson merged commit 8bf8b02 into master Jul 30, 2026
17 checks passed
@tonythethompson
tonythethompson deleted the fix/release-pipeline-followups branch July 30, 2026 12:33
@linear-code

linear-code Bot commented Jul 30, 2026

Copy link
Copy Markdown

NUM-16

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant