Repository navigation
fix(release): re-enable the winget release job - #763
Conversation
keboola-pr-reviewer-bot
left a comment
There was a problem hiding this comment.
Verdict: needs_human (risk 4/5) · profile _default
Head commit has failing checks (check, test (3.12)); no required-check rules discovered on the base branch, falling back to block-on-any-failure.
There was a problem hiding this comment.
🔵 Needs a closer look
Remove the Chocolatey gating risk and update the now-stale README guidance.
Pull request overview
Re-enables automated WinGet publishing for stable tagged releases now that the package manifest exists.
Changes:
- Restores the stable-tag condition for the
wingetjob. - Updates comments documenting the completed bootstrap manifest.
- Uses the existing
WINGET_TOKENsecret.
File summaries
| File | Summary | Findings |
|---|---|---|
.github/workflows/release-kbagent.yml |
Re-enables and documents WinGet release publishing. | Moderate (1 vote): Chocolatey remains a transitive dependency and can prevent WinGet publishing. Nit (1 vote): Update README.md package-manager guidance. |
Review details
Suppressed comments (2)
.github/workflows/release-kbagent.yml:625
- Once this job is re-enabled,
README.md:53still tells users that no WinGet package exists or has been submitted. That will become incorrect after the next tagged release, so please update the current package-manager guidance alongside this workflow (historical changelog notes can remain historical).
# The one-time bootstrap `wingetcreate submit` this job used to be blocked on
# has already happened by hand: `Keboola.KeboolaCLI2` has a manifest on
# microsoft/winget-pkgs starting at 0.79.0 (winget-pkgs PR #409446). That
# manifest is what `wingetcreate update` below now bumps on every release.
.github/workflows/release-kbagent.yml:628
- Now that this condition activates the job, it is still transitively gated by
chocolateythroughneeds; a Chocolatey publish failure (or duplicate-version rerun) makes GitHub skip WinGet even though WinGet only consumes the S3 ZIP produced bypublish-s3. That can silently miss the WinGet PR, so removechocolateyfrom this dependency (or explicitly handle its failure withalways()).
needs: [version, chocolatey, publish-s3]
if: needs.version.outputs.IS_PRERELEASE == 'false' && startsWith(github.ref, 'refs/tags/')
- Files reviewed: 1/1 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
b196421 to
defe8e6
Compare
The wingetcreate bootstrap submission this job was waiting on has already happened by hand (Keboola.KeboolaCLI2 0.79.0 manifest merged into microsoft/winget-pkgs on 2026-09-07, PR #409446), so `wingetcreate update` now has an existing manifest to bump. Restore the real trigger condition so future tagged releases publish to winget again instead of silently skipping it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
defe8e6 to
009dbda
Compare
soustruh
left a comment
There was a problem hiding this comment.
Approved. Minimal, scoped fix that re-enables the winget release job. CI is green.
Summary
wingetjob in.github/workflows/release-kbagent.yml, restoring its original trigger condition (needs.version.outputs.IS_PRERELEASE == 'false' && startsWith(github.ref, 'refs/tags/')) in place of the hardcodedif: false.Keboola.KeboolaCLI2had "never had its first submission" tomicrosoft/winget-pkgs, blockingwingetcreate updatefrom having anything to bump.wingetcreate submitwas already done by hand on 2026-09-07 (microsoft/winget-pkgsPR #409446), creating theKeboola.KeboolaCLI2manifest starting at version0.79.0. Nobody flipped the job back on afterward, so every release since (up through the current0.93.2) has silently skipped winget publishing even though the blocker was gone.WINGET_TOKENis already present as arelease-environment secret (set 2026-06-15), so no secret changes are needed here.Test plan
Keboola.KeboolaCLI2manifest exists onmicrosoft/winget-pkgs@master(manifests/k/Keboola/KeboolaCLI2/0.79.0) and thatWINGET_TOKENis set in this repo'sreleaseenvironment.wingetjob locally (it publishes to an external repo and only runs on a real version tag); the real verification is watching the job on the next tagged release and confirming a newmicrosoft/winget-pkgsPR opens with the correct version/URL/hash.Related
WINGET_TOKEN), whose text about the bootstrap submission being outstanding is now stale — this PR is the actual fix that makes the job run again.