Conversation
…ble binaries The README showed one page of the app. The collage at the top now shows the four surfaces someone would actually use: the Wallpapers grid with images tagged, the Settings page with the day/night bar, the tray menu with everything it can do without opening the window, and the close prompt. Captured on Windows 11 in the light theme with a real folder of twelve images, composited over the same day-to-night sweep as the banner. Publishing binaries only ever happened on a v* tag, and a manual run could not publish at all without creating a release tagged after the branch it ran from. Now the version job resolves what is being built: - A pushed v* tag is a release. It keeps its own tag, is drafted so the notes can be read before anyone sees it, and becomes "latest". - A manual run with "publish" ticked is a development build. It is tagged <branch>-<version>, published straight away rather than drafted so the point of it — being downloadable — actually holds, and marked prerelease and never "latest" so it cannot be mistaken for a release. Successive builds from the same branch replace each other instead of piling up, and the notes say plainly what the build is and which commit it came from. A manual run without "publish" is unchanged: it builds and checks all six artifacts and publishes nothing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0f262f76ce
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| tag_name: v${{ needs.version.outputs.version }} | ||
| name: Wallpaper Switcher ${{ needs.version.outputs.version }} | ||
| # would be a bare branch name, and the release would be tagged with it. | ||
| tag_name: ${{ needs.version.outputs.tag }} |
There was a problem hiding this comment.
When workflow_dispatch publishes from a branch, this synthetic tag does not exist yet and the action receives no target_commitish. GitHub's release-create documentation states: “If a matching git tag does not yet exist, one will automatically get created from the latest state of the default branch.” The binaries and notes therefore describe the selected branch's GITHUB_SHA, while the tag and GitHub-generated source archives point to the default branch; subsequent replacements also leave that tag at its old commit. Create or update the tag at GITHUB_SHA rather than relying on release creation.
Useful? React with 👍 / 👎.
| if [ "$GITHUB_REF_TYPE" = tag ]; then | ||
| echo "channel=release" >> "$GITHUB_OUTPUT" | ||
| echo "tag=$GITHUB_REF_NAME" >> "$GITHUB_OUTPUT" | ||
| echo "name=Wallpaper Switcher $version" >> "$GITHUB_OUTPUT" |
There was a problem hiding this comment.
When a manual dispatch selects a tag ref, GITHUB_REF_TYPE is tag even though the required version input can name a different version. For example, dispatching from v0.7.0 with version=0.8.0 makes this workflow upload 0.8.0-named artifacts and notes to the existing v0.7.0 release; the publish condition also runs for any tag ref regardless of the manual publish checkbox. Only tag-push events should derive the release tag from GITHUB_REF_NAME; manual events should use a separately validated development tag.
Useful? React with 👍 / 👎.
| branch="${GITHUB_REF_NAME//\//-}" | ||
| echo "channel=dev" >> "$GITHUB_OUTPUT" | ||
| echo "tag=$branch-$version" >> "$GITHUB_OUTPUT" |
There was a problem hiding this comment.
Replacing every slash with - is not injective: valid branches such as feature/foo and feature-foo both produce feature-foo-<version>. Publishing the second branch at the same version consequently updates the first branch's prerelease and replaces or mixes its assets, contrary to the stated per-branch replacement behavior. Encode the branch name unambiguously or include a stable branch identifier in the tag.
Useful? React with 👍 / 👎.
1 participant
No description provided.