Create promote-beta-to-stable skill#2955
Conversation
Co-Authored-By: Claude Opus 4.6 <[email protected]>
|
@BugBot run |
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request focuses on enhancing the release automation capabilities by adding a new skill that streamlines the promotion of beta versions to stable releases. This new skill encapsulates the entire process, from identifying the latest pre-release to creating and pushing the stable release branch, thereby reducing manual effort and potential errors in the release workflow. Concurrently, the project's Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is ON, but it could not run because Privacy Mode (Legacy) is turned on. To enable Bugbot Autofix, switch your privacy mode in the Cursor dashboard.
| { | ||
| "name": "dyad", | ||
| "version": "0.39.0-beta.1", | ||
| "version": "0.39.0", |
There was a problem hiding this comment.
package-lock.json version not updated to match package.json
Medium Severity
The version in package.json was bumped to 0.39.0, but package-lock.json still contains 0.39.0-beta.1 (at lines 3 and 9). This version mismatch means the lockfile is out of sync with the manifest, which can cause inconsistencies in build tooling or CI that reads the version from the lockfile.
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
Greptile SummaryThis PR bumps Key changes:
Confidence Score: 4/5
Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A["/dyad:promote-beta-to-stable invoked"] --> B["gh release list\n--json tagName,isPrerelease"]
B --> C{Pre-release found?}
C -- No --> D[Report & stop]
C -- Yes --> E["git fetch upstream --tags\ngit rev-parse <tag>\n⚠️ Returns tag object SHA\nfor annotated tags"]
E --> F["Parse MAJOR.MINOR\nfrom tag name"]
F --> G["git checkout -b release-MAJOR.MINOR.x <sha>\n⚠️ Fails if SHA is a tag object"]
G --> H["Edit package.json\nStrip pre-release suffix"]
H --> I["git add package.json\ngit commit -m 'Bump to vX.Y.Z'"]
I --> J["git push upstream release-MAJOR.MINOR.x"]
J --> K[Summarize results]
Last reviewed commit: 7630695 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
|
|
||
| ``` | ||
| git fetch upstream --tags | ||
| git rev-parse <tag> |
There was a problem hiding this comment.
git rev-parse <tag> returns the tag object SHA for annotated tags, not the commit SHA
GitHub releases always create annotated tags. For annotated tags, git rev-parse <tag> returns the SHA of the tag object, not the underlying commit. When that tag-object SHA is passed to git checkout -b in step 4, Git will fail with:
fatal: reference is not a tree: <tag-object-sha>
To fix, dereference the tag using ^{} to guarantee a commit SHA is returned:
| git rev-parse <tag> | |
| git rev-parse <tag>^{} |
Alternatively, step 4 could use the tag name directly (git checkout -b release-MAJOR.MINOR.x <tag>) to let Git automatically dereference the annotated tag.
Prompt To Fix With AI
This is a comment left during a code review.
Path: .claude/skills/promote-beta-to-stable/SKILL.md
Line: 28
Comment:
`git rev-parse <tag>` returns the tag object SHA for annotated tags, not the commit SHA
GitHub releases always create annotated tags. For annotated tags, `git rev-parse <tag>` returns the SHA of the **tag object**, not the underlying commit. When that tag-object SHA is passed to `git checkout -b` in step 4, Git will fail with:
```
fatal: reference is not a tree: <tag-object-sha>
```
To fix, dereference the tag using `^{}` to guarantee a commit SHA is returned:
```suggestion
git rev-parse <tag>^{}
```
Alternatively, step 4 could use the tag name directly (`git checkout -b release-MAJOR.MINOR.x <tag>`) to let Git automatically dereference the annotated tag.
How can I resolve this? If you propose a fix, please make it concise.
🔍 Dyadbot Code Review SummaryVerdict: ⛔ NO - Do NOT merge Reviewed by 3 independent agents: Correctness Expert, Code Health Expert, UX Wizard. Issues Summary
🟢 Low Priority Notes (2 items)
🚫 Dropped False Positives (0 items)None — all flagged issues were confirmed valid. Generated by Dyadbot multi-agent code review |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a new 'promote-beta-to-stable' skill to automate the release process and applies it by bumping the version to v0.39.0. The implementation of the skill is well-structured. I've added one suggestion to make the skill more robust by handling cases where a release branch already exists.
Note: Security Review has been skipped due to the limited scope of the PR.
| 4. **Create the release branch from the pre-release commit:** | ||
|
|
||
| ``` | ||
| git checkout -b release-MAJOR.MINOR.x <commit-sha> | ||
| ``` |
There was a problem hiding this comment.
The instruction git checkout -b ... will fail if the release branch (e.g., release-0.39.x) already exists. This is a likely scenario when promoting a patch release on an existing release line. To make the skill more robust, it should explicitly check for the branch's existence and abort if found.
Here is a suggested update for this step:
4. **Create the release branch from the pre-release commit:**
First, check if the release branch already exists on `upstream`. If it does, report an error and stop.git ls-remote --exit-code --heads upstream release-MAJOR.MINOR.x
If the command fails with exit code 2, the branch does not exist. Proceed to create it:
git checkout -b release-MAJOR.MINOR.x
![dyad-assistant[bot]](https://avatars.githubusercontent.com/in/3027874?s=60&v=4){kind=small}
| { | ||
| "name": "dyad", | ||
| "version": "0.39.0-beta.1", | ||
| "version": "0.39.0", |
There was a problem hiding this comment.
🔴 HIGH | data-integrity
package-lock.json not updated to match version bump
package.json was bumped to 0.39.0 but package-lock.json still has 0.39.0-beta.1 (both in version and packages[""].version). This version mismatch can cause npm ci failures and inconsistent builds.
💡 Suggestion: Run npm install --package-lock-only to regenerate the lockfile, then commit the updated package-lock.json.
| - `1.2.0-beta.3` → `1.2.0` | ||
|
|
||
| Use the Edit tool to make this change. | ||
|
|
There was a problem hiding this comment.
🟡 MEDIUM | missing-step
Skill does not update package-lock.json after bumping package.json
Step 5 only edits package.json, but package-lock.json also contains the version string. Future runs of this skill will produce the same version mismatch bug seen in this PR.
💡 Suggestion: Add a substep after editing package.json to run npm install --package-lock-only, and update step 6 to stage both files: git add package.json package-lock.json.
![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: 7630695ea3
ℹ️ 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".
| 4. **Create the release branch from the pre-release commit:** | ||
|
|
||
| ``` | ||
| git checkout -b release-MAJOR.MINOR.x <commit-sha> |
There was a problem hiding this comment.
Step 4 always runs git checkout -b release-MAJOR.MINOR.x <commit-sha>, but git checkout -h documents -b as “create and checkout a new branch,” so this fails whenever that release branch already exists (for example, promoting a second beta for the same MAJOR.MINOR line or rerunning after a partial failure). In those cases the skill aborts before the version bump and push, which breaks the intended autonomous release flow.
Useful? React with 👍 / 👎.
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
1 issue found across 3 files
Confidence score: 4/5
- This PR is likely safe to merge, with one moderate-risk workflow issue rather than a product-facing break.
- In
.claude/skills/promote-beta-to-stable/SKILL.md, usinggit checkout -bcan fail when the release branch already exists, which may disrupt reruns or second beta promotions on the same release line. - Given the issue is severity 5/10 (confidence 8/10) and appears scoped to release process instructions, risk is real but limited in blast radius.
- Pay close attention to
.claude/skills/promote-beta-to-stable/SKILL.md- branch creation should handle pre-existing release branches to avoid promotion failures.
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name=".claude/skills/promote-beta-to-stable/SKILL.md">
<violation number="1" location=".claude/skills/promote-beta-to-stable/SKILL.md:44">
P2: `git checkout -b` will fail if the release branch already exists (e.g., when promoting a second beta on the same release line, or rerunning after a partial failure). Consider checking for the branch's existence first, or using `git checkout -B` which resets the branch if it already exists.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
| 4. **Create the release branch from the pre-release commit:** | ||
|
|
||
| ``` | ||
| git checkout -b release-MAJOR.MINOR.x <commit-sha> |
There was a problem hiding this comment.
P2: git checkout -b will fail if the release branch already exists (e.g., when promoting a second beta on the same release line, or rerunning after a partial failure). Consider checking for the branch's existence first, or using git checkout -B which resets the branch if it already exists.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At .claude/skills/promote-beta-to-stable/SKILL.md, line 44:
<comment>`git checkout -b` will fail if the release branch already exists (e.g., when promoting a second beta on the same release line, or rerunning after a partial failure). Consider checking for the branch's existence first, or using `git checkout -B` which resets the branch if it already exists.</comment>
<file context>
@@ -0,0 +1,78 @@
+4. **Create the release branch from the pre-release commit:**
+
+ ```
+ git checkout -b release-MAJOR.MINOR.x <commit-sha>
+ ```
+
</file context>
🎭 Playwright Test Results❌ Some tests failed
Summary: 760 passed, 6 failed, 8 flaky, 244 skipped Failed Tests🍎 macOS
🪟 Windows
📋 Re-run Failing Tests (macOS)Copy and paste to re-run all failing spec files locally: npm run e2e \
e2e-tests/visual_editing.spec.ts
|
1 participant
Summary
Test plan
🤖 Generated with Claude Code