fix(build): name Etienne Lescot as the Windows publisher - #246
fix(build): name Etienne Lescot as the Windows publisher#246EtienneLescot wants to merge 3 commits into
Conversation
Windows listed the installed app's publisher as the original creator. electron-builder derives it from package.json `author.name` only (appInfo.companyName -> NSIS COMPANY_NAME), so that is the field that had to change; there is no win.publisherName override in electron-builder 26. Siddharth Vaddem moves to `contributors`; README and LICENSE keep crediting him as the original creator. The appx target was already correct via its own publisherDisplayName.
The 1.8.0 sync turned `onStatus` from a bare phase into an `SttRendererStatus` object carrying chunk progress, but the CLI captions runner still declared the old `(phase) => void` callback. Neither branch was broken alone; the rebase in #245 put them together and main has not typechecked since. `onStatus` now also fires once per transcribed chunk rather than once per phase, so log only on a phase change -- otherwise a long transcription emits one identical line per chunk.
… tag docs.yml had an `on: release` trigger so the /download page could pick up the new assets. It could never work: a release event runs with github.ref = refs/tags/vX.Y.Z, and the github-pages environment allows only `main` to deploy, so the deploy job failed on every stable release. Pre-releases skipped the build entirely, which is why v1.8.0 was the first release to surface it. Replace the trigger with a workflow_dispatch fired by build.yml once the release is published. Dispatching against main satisfies the environment policy and publishes main's docs rather than the release branch snapshot.
📝 WalkthroughWalkthroughThe pull request updates package authorship metadata, release-triggered documentation workflows, and CLI transcription status logging. ChangesPackage metadata
Release documentation workflow
CLI transcription status
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
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/build.yml:
- Around line 511-521: Update the “Refresh the docs /download page” step to
capture the run ID returned by `gh workflow run docs.yml --ref main`, then
monitor that dispatched run until completion with the GitHub CLI and fail the
release step if the docs build or deployment fails. Preserve the existing
stable-release condition and main-branch dispatch.
🪄 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: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 40906b8d-e1f4-4f5d-a045-cfcab564b700
📒 Files selected for processing (3)
.github/workflows/build.yml.github/workflows/docs.ymlsrc/cli/CliCaptionsRunner.tsx
| - name: Refresh the docs /download page | ||
| # Only a stable release changes what /releases/latest resolves to, so a | ||
| # pre-release would rebuild the site to byte-identical output. | ||
| # | ||
| # Dispatched against main on purpose: the github-pages environment only | ||
| # permits `main` to deploy, so docs.yml's old `on: release` trigger ran | ||
| # with a tag ref and failed its deploy every time. See docs.yml. | ||
| if: ${{ steps.release.outputs.is_prerelease == 'false' }} | ||
| env: | ||
| GH_TOKEN: ${{ secrets.OPENSCREEN_RELEASE_TOKEN }} | ||
| run: gh workflow run docs.yml --ref main --repo "$GITHUB_REPOSITORY" |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== workflow files =="
git ls-files '.github/workflows/*' | sed -n '1,120p'
echo
echo "== build.yml relevant section =="
sed -n '440,540p' .github/workflows/build.yml || true
echo
echo "== docs.yml ref =="
sed -n '1,220p' .github/workflows/docs.yml || true
echo
echo "== gh workflow run docs.yml references =="
rg -n "gh workflow run|publish-release|GH_TOKEN|OPENSCREEN_RELEASE_TOKEN|refs/tags|workflow_dispatch" .github/workflows || trueRepository: getopenscreen/openscreen
Length of output: 11815
🌐 Web query:
GitHub CLI gh workflow run --watch option documentation
💡 Result:
The gh workflow run command in the GitHub CLI does not currently have a --watch flag [1][2]. To monitor the progress of a workflow run triggered via the CLI, you should use the gh run watch command [3][4]. Because gh workflow run does not support an automatic watch option, common workflows involve running the command and then using gh run watch to track the result [5]. For example, after triggering a workflow, you can use gh run watch to interactively select the run or watch a specific run ID [6][3]: $ gh run watch If you want to view a run that was just triggered, you can use gh run watch without arguments to see an interactive list of recent runs, or use gh run list to find the ID of the latest run and pass it to gh run watch [6][5]. While community requests for a native --watch option on the workflow run command have been tracked [5], it has not been implemented as of August 2026.
Citations:
- 1: https://cli.github.com/manual/gh_workflow_run
- 2: https://github.com/tenequm/skills/blob/main/skills/gh-cli/references/actions.md
- 3: https://docs.github.com/en/actions/how-tos/manage-workflow-runs/manually-run-a-workflow?tool=webui
- 4: https://github.com/github/docs/blob/main/content/actions/how-tos/manage-workflow-runs/manually-run-a-workflow.md
- 5: Add option to watch workflow run progress cli/cli#3559
- 6: https://cli.github.com/manual/gh_run_watch
🌐 Web query:
site:cli.github.com manual gh workflow run --watch dispatches workflow
💡 Result:
The command 'gh workflow run --watch' is not a valid GitHub CLI command. The 'gh workflow run' command triggers a workflow and does not accept a '--watch' flag [1][2]. If you want to dispatch a workflow and then watch it, you must run two separate commands in sequence: 1. Use 'gh workflow run' to trigger the workflow [1]. 2. Use 'gh run watch' to monitor the resulting workflow run [3][4]. Example usage: gh workflow run && gh run watch The 'gh workflow run' command is used to create a 'workflow_dispatch' event for a specific workflow [1], while 'gh run watch' is used to monitor an existing run until it completes [3].
Citations:
- 1: https://cli.github.com/manual/gh_workflow_run
- 2: https://cli.github.com/manual/gh_workflow
- 3: https://cli.github.com/manual/gh_run_watch
- 4: https://cli.github.com/manual/gh_run
Monitor the documentation deployment before completing the release.
gh workflow run docs.yml --ref main only dispatches the workflow and exits. If the downstream docs.yml build or GitHub Pages deployment fails, the release step completes successfully while /download can continue serving the previous release. Capture the dispatched run ID and poll it to completion, for example with gh run watch --run-id ..., or add a monitored retry/alert path.
🤖 Prompt for 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.
In @.github/workflows/build.yml around lines 511 - 521, Update the “Refresh the
docs /download page” step to capture the run ID returned by `gh workflow run
docs.yml --ref main`, then monitor that dispatched run until completion with the
GitHub CLI and fail the release step if the docs build or deployment fails.
Preserve the existing stable-release condition and main-branch dispatch.
Source: MCP tools
2 participants
Windows listed the installed app's publisher as the original creator (see the Apps list entry for 1.8.0-rc.7 and earlier).
electron-builder derives that string from
package.jsonauthor.nameand nowhere else:appInfo.companyNamereturnsmetadata.author.name(app-builder-lib/out/appInfo.js:90)NsisTarget.js:488setsCOMPANY_NAMEfrom it — that is thePublishervalue Windows showsAppxTarget.js:184usespublisherDisplayName || companyName, which is why the Store package was already correctThere is no
win.publisherNameoverride in electron-builder 26 — that key was removed from thewinschema and now fails config validation outright.So
author.namebecomes Etienne Lescot. Siddharth Vaddem moves tocontributors; README and LICENSE continue to credit him as the original creator, and the LICENSE copyright line is untouched.Already shipped on
release/v1.8.0(tagv1.8.0was re-cut at40444d5aand rebuilt). This ports it to main so 1.8.1 doesn't regress.Summary by CodeRabbit
Bug Fixes
Documentation
Chores