build(winget): package okf-render as Coderise.OKF4net.Render - #80
Merged
Conversation
…t.Render) okf-render ships alongside okf but had no winget package of its own. Add a second package identifier, Coderise.OKF4net.Render, mirroring okf's shape: - New manifest templates (version/installer/locale) under packaging/winget/templates/, describing the static-site generator rather than reusing okf's validator copy; installer template nests okf-render.exe with the okf-render command alias. - Generate-Manifests.ps1 gains a -PackageIdentifier parameter so one script fills either package's three templates, matched by exact filename (a prefix/glob match would wrongly pull Coderise.OKF4net.Render's templates in when generating Coderise.OKF4net, since the former string starts with the latter). - release.yml's winget-manifests job now generates and attaches manifests for both packages, reading the render zips' own .sha256 sidecars. A new winget-submit-render job mirrors winget-submit (same WINGET_TOKEN gate, same skip-with-notice behaviour) with its own installers-regex anchored to okf-render-<version>-win-*.zip so it cannot match okf's zips, and vice versa -- verified in both directions against real archive names and against the non-Windows tar.gz names that neither regex should match. - Docs: packaging/winget/README.md now covers both packages and states plainly that Coderise.OKF4net.Render's first winget-pkgs submission must still be done by hand (winget-releaser updates an existing package, it does not create one). README.md's okf-render section drops the stale "not currently packaged for winget" line in favour of the same caveat. Verified locally: ran Generate-Manifests.ps1 for both packages with plausible version/URL/SHA256 values, confirmed `winget validate` passes on both generated manifest sets, and confirmed both installers-regex patterns against each other's zip names plus .tar.gz names. dotnet test OKF4net.sln (1272 passed) and dotnet format --verify-no-changes both stay clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
🟡 Changes recommended
winget-submit-render can still run (and fail the release workflow) as soon as WINGET_TOKEN is configured, even if the render package is not yet present in winget-pkgs.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
Adds a dedicated winget package identity for the okf-render static-site generator and updates the release pipeline/scripts so both okf and okf-render winget manifests can be generated and (eventually) submitted.
Changes:
- Add winget manifest templates for
Coderise.OKF4net.Render(version/defaultLocale/installer). - Generalize
packaging/winget/Generate-Manifests.ps1with-PackageIdentifierto generate manifests for either package without duplicating the script. - Extend
release.ymlto generate/attach both packages’ manifests and add a mirroredwinget-submit-renderjob.
File summaries
| File | Description |
|---|---|
| README.md | Updates user-facing install guidance to mention the new winget package and its manual first submission requirement. |
| packaging/winget/templates/Coderise.OKF4net.Render.yaml.in | Adds the winget “version” manifest template for the render package. |
| packaging/winget/templates/Coderise.OKF4net.Render.locale.en-US.yaml.in | Adds localized metadata (publisher/name/description/tags) for the render package. |
| packaging/winget/templates/Coderise.OKF4net.Render.installer.yaml.in | Adds installer manifest template pointing to okf-render.exe as a portable nested installer. |
| packaging/winget/README.md | Documents the two-package setup, regex separation, and manual first submission for the render package. |
| packaging/winget/Generate-Manifests.ps1 | Adds -PackageIdentifier and switches to exact-filename template selection to avoid prefix collisions. |
| .github/workflows/release.yml | Generates/attaches both manifest sets and adds a winget-submit-render job for automated updates. |
Review details
- Files reviewed: 7/7 changed files
- Comments generated: 1
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Comment on lines
+275
to
+285
| - name: Check for a winget token | ||
| id: gate | ||
| env: | ||
| WINGET_TOKEN: ${{ secrets.WINGET_TOKEN }} | ||
| run: | | ||
| if [ -z "$WINGET_TOKEN" ]; then | ||
| echo "::notice::No WINGET_TOKEN secret; skipping the winget-pkgs PR. The manifests are attached to the Release -- submit them with \`wingetcreate submit\`." | ||
| echo "go=false" >> "$GITHUB_OUTPUT" | ||
| else | ||
| echo "go=true" >> "$GITHUB_OUTPUT" | ||
| fi |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Gives the new
okf-renderbinary its own winget package, mirroring howokfis already published asCoderise.OKF4net.What ships
Coderise.OKF4net.Render, with copy that describes this tool rather than repeating the validator's: it installs theokf-rendercommand, points at theokf-render-*zips, and its short description is about static-site generation, not parsing/validating.Generate-Manifests.ps1gains a-PackageIdentifierparameter and produces either package's manifests, rather than being forked into a second near-identical script.release.yml: thewinget-manifestsjob now generates and attaches both packages' manifests; a newwinget-submit-renderjob mirrors the existing submit job, including its token guard — it skips with a notice unless aWINGET_TOKENsecret exists.The first submission is manual, on purpose
winget-releaserupdates an existing package; it does not create one. SoCoderise.OKF4net.Render's first appearance in winget-pkgs has to be submitted by hand — exactly asCoderise.OKF4netwas. The new job is deliberately inert until then, andpackaging/winget/README.mdnow says so plainly so nobody expects it to publish a package that does not exist yet. Once the package is live and a token is configured, both packages activate together.Two traps worth recording
Coderise.OKF4netis a literal string prefix ofCoderise.OKF4net.Render. Matching templates by prefix or glob would silently pick up the wrong file. Generation matches by exact filename instead.installers-regexis per-job, and the two packages' Windows zips live side by side on the same Release. Both regexes are anchored and were verified in both directions — each matches only its own package's two zips and rejects the other's, plus every.tar.gz:Getting that wrong would submit the wrong binary to Microsoft.
Verified
Both manifest sets generated locally with real-shaped URLs and checked: distinct identifiers, distinct command aliases (
okfvsokf-render), correctRelativeFilePathper package, correct URLs.winget validate --manifest(CLI v1.30.130-preview) returned success for both. 1272 tests green,dotnet formatclean.Not verifiable without a real release: an end-to-end CI run of the new job, and installing from a published artifact.
🤖 Generated with Claude Code