fix(store): the option is --inputDirectory, and it takes a directory

[EtienneLescot]

The dry run from #380 paid for itself immediately.

What it found

DRY RUN: submitting Openscreen.Setup.1.9.5.appx as a draft only
Unrecognized command or argument '--inputFile'.

The CLI then printed its usage, which disagrees with the published documentation:

-i, --inputDirectory <inputDirectory>   The directory where the '.msix' or
                                        '.msixupload' file to be used for the
                                        publishing command...

Microsoft Learn documents -i, --inputFile, "the path to the '.msix' or '.msixupload' file". The binary that microsoft/microsoft-store-apppublisher@v1.1 installs takes --inputDirectory and wants the folder. I wrote #379 from the documentation; the binary is what runs.

Corrected at both call sites — build.yml carried the same mistake, since that is where the first fix landed.

Everything else on that run worked

Tag validated · configuration resolved · tag checked out · build run resolved and matched by head_sha · artifact downloaded · CLI configured · submission reached the point of parsing its own arguments. Only the option name was wrong.

So this is the last known unknown before the open .appx question — the usage text still says .msix/.msixupload, and we produce .appx. The next dry run answers it the same cheap way, in about ninety seconds, without putting anything in front of users.

The point worth keeping

This is precisely the failure the dry run existed to absorb. Without it, the "fix" from #379 would have been discovered broken by the next stable release — after a full build, after the release was published, and with the same unusable retry story that started all of this.

Both workflows re-validated: YAML parses, all bash steps pass bash -n, publish-msstore.yml's pwsh block parses clean. (build.yml's submit block cannot be parsed standalone — it interpolates four ${{ secrets.* }} into the script, which Actions substitutes before pwsh sees them.)

[coderabbitai]

Warning

Review limit reached

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

Next review available in: 13 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

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: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 363f3041-8835-442c-9bf8-d090ae336ae0

📥 Commits

Reviewing files that changed from the base of the PR and between ae13d5b and eaa6b1f.

📒 Files selected for processing (2)

• .github/workflows/build.yml
• .github/workflows/publish-msstore.yml

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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