fix(ci): handle initial WinGet submission with wingetcreate new

[elkaix]

Summary

• winget.yml previously always called wingetcreate update, which fails when the package doesn't exist yet in microsoft/winget-pkgs
• Now detects whether PythoughtsLabs.PythinkerCode exists via the GitHub API before running
• Uses wingetcreate new for the initial submission, wingetcreate update for all subsequent releases
• No change to trigger (still manual workflow_dispatch only)

Summary by CodeRabbit

• Chores
  • Updated Windows Package Manager submission workflow to detect whether a package manifest already exists: CI will perform automated updates when an existing manifest is found; if no manifest exists, the workflow stops and instructs submitting the initial manifest manually.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 0292cae7-ec94-4fad-88b1-9a26da736914

📥 Commits

Reviewing files that changed from the base of the PR and between 2a37f19 and ce10b0d.

📒 Files selected for processing (1)

• .github/workflows/winget.yml

---

📝 Walkthrough

Walkthrough

The workflow checks microsoft/winget-pkgs for the target manifestPath; if present it runs wingetcreate update with installer URL and version, otherwise it fails and instructs the user to perform the initial wingetcreate new manually.

Changes

Conditional WinGet submission

Layer / File(s)	Summary
Manifest existence check and conditional update .github/workflows/winget.yml	Step name changed to reflect "new or update". The workflow queries the microsoft/winget-pkgs contents API using WINGET_TOKEN for the manifestPath; on 200 it runs wingetcreate update with installer URL and version, on 404 it fails with an instruction to perform the initial wingetcreate new manually; non-404 errors cause the workflow to fail.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Suggested labels

bug

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	❓ Inconclusive	The description provides clear context on the change but is missing the required checklist items and related issue link from the template.	Add the required sections: link the related issue with 'Resolve #(issue_number)', and complete the checklist items to confirm testing, changelog, and documentation updates.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title follows conventional commits format (fix(ci): ...) and clearly describes the main change: handling initial WinGet submission with wingetcreate new.
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.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/winget-new-submission

---

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

[coderabbitai]

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/winget.yml:
- Around line 66-72: The catch block currently treats all errors as "not found";
update the catch after Invoke-WebRequest to inspect the HTTP status code on the
caught exception (from $_.Exception.Response or
$_.Exception.Response.StatusCode) and only set $packageExists = $false when that
code is 404; for any other status (401, 403, 5xx, network errors) rethrow or
throw the original exception so the workflow fails loudly. Locate the
Invoke-WebRequest call and the catch that sets $packageExists and replace the
blanket assignment with this conditional logic.
- Around line 83-87: The CI currently calls the interactive command
"wingetcreate.exe new" with automation flags (--id, --version, --submit,
--token) which can hang or fail; change the workflow to use a non-interactive
flow by replacing the interactive "wingetcreate.exe new" invocation with
"wingetcreate.exe update" for subsequent runs (or run "wingetcreate new" once
locally to generate the manifest, commit it, then use "wingetcreate.exe update
$installerUrl --id PythoughtsLabs.PythinkerCode --version $env:VERSION --submit
--token $env:WINGET_TOKEN" in the CI) so the job no longer invokes the
interactive wizard (update uses the existing manifest and is non-interactive).

🪄 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: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 255f722e-ed4e-41d2-991c-5d03fa344248

📥 Commits

Reviewing files that changed from the base of the PR and between 5a49492 and 2a37f19.

📒 Files selected for processing (1)

• .github/workflows/winget.yml

[elkaix]

Addressed both inline findings in ce10b0d:

Finding 1 (catch block, lines 66-72) — Fixed. The catch now inspects `$_.Exception.Response`:

• `$response == null` (network error) → rethrows
• HTTP status ≠ 404 (401, 403, 5xx) → rethrows
• HTTP 404 → sets `$packageExists = $false`

Finding 2 (wingetcreate new, lines 83-87) — Fixed. Removed `wingetcreate new` from CI entirely. It is interactive and can hang even with automation flags. The `else` branch now throws a clear error message directing the operator to run `wingetcreate new` manually once for the initial submission. After that PR is merged into `winget-pkgs`, all future releases go through `wingetcreate update` (non-interactive, fully automated).