Tagged releases#944
Conversation
|
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 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: 3
🤖 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/release-tagged:
- Line 1: The workflow is currently defined in a file without a YAML extension,
so GitHub Actions will not discover it. Rename the workflow file that contains
the Release job to use a valid workflow extension such as release-tagged.yml or
release-tagged.yaml, keeping the workflow contents unchanged.
- Line 5: The branch filter in the release workflow has a typo that prevents
matching the intended next branch. Update the branches list in the
release-tagged workflow so the branch pattern is valid and references the
intended next branch correctly; verify the branch filter syntax around the
branches configuration so pushes to next are matched as expected.
In `@package.json`:
- Line 34: The release-tagged publish command is using git branch
--show-current, which can be empty in detached GitHub Actions checkouts and lead
to an empty dist-tag. Update the release-tagged script in package.json to use
the workflow ref name instead, and wire the value in from github.ref_name or a
RELEASE_TAG environment variable so changeset publish always receives a valid
tag.
🪄 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: b9179393-fac4-44c3-8bb9-d69a74d66196
📒 Files selected for processing (2)
.github/workflows/release-taggedpackage.json
| @@ -0,0 +1,34 @@ | |||
| name: Release | |||
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf 'Repository workflow files:\n'
git ls-files '.github/workflows/*' || true
printf '\nTarget file details:\n'
stat -c '%n %F %s bytes' '.github/workflows/release-tagged' 2>/dev/null || true
printf '\nFirst 80 lines of target file:\n'
cat -n '.github/workflows/release-tagged' 2>/dev/null | sed -n '1,80p'Repository: solidjs-community/solid-primitives
Length of output: 1399
🌐 Web query:
GitHub Actions workflow files .github/workflows extension requirement .yml .yaml official docs
💡 Result:
For GitHub Actions workflow files stored in the.github/workflows directory, both.yml and.yaml file extensions are fully supported and functionally identical [1][2][3]. GitHub will automatically discover and execute workflow files using either extension [2][3]. While both are officially supported, the choice is a matter of personal or organizational preference [3]. It is recommended to maintain consistency within a repository to avoid confusion [3]. Separately, if you are creating custom Actions (which are distinct from workflows), their metadata files also support both.yml and.yaml extensions [4][5]. However, in the context of custom Actions, the official documentation expresses a preference for the.yml extension [4]. If you change the file extension of a custom action's metadata file (e.g., from.yml to.yaml) after it has been published to the GitHub Marketplace, it may cause previous versions to be hidden from the Marketplace [4].
Citations:
- 1: https://docs.github.com/actions/using-workflows/workflow-syntax-for-github-actions
- 2: https://docs.github.com/actions/get-started/quickstart
- 3: https://www.getorchestra.io/guides/is-yml-or-yaml-file-extension-necessary-for-github-actions
- 4: https://docs.github.com/en/actions/reference/workflows-and-actions/metadata-syntax
- 5: https://stackoverflow.com/questions/76721309/location-of-action-yaml-or-action-yml-files
🌐 Web query:
site:docs.github.com GitHub Actions workflow files extension yml yaml discover workflow files ignored without extension
💡 Result:
GitHub Actions requires that all workflow files located in the.github/workflows directory have either a.yml or.yaml file extension [1][2]. Files placed within this directory that do not have one of these two extensions will be ignored by GitHub Actions and will not be discovered or triggered as workflows [2][3]. The workflow files must also be stored in the.github/workflows directory of your repository to be detected [1][3].
Citations:
- 1: https://docs.github.com/actions/using-workflows/workflow-syntax-for-github-actions
- 2: https://docs.github.com/actions/get-started/quickstart
- 3: https://docs.github.com/actions/using-workflows/about-workflows
🌐 Web query:
site:docs.github.com "workflow file" ".github/workflows" ".yml" ".yaml" GitHub Actions
💡 Result:
In GitHub Actions, a workflow file is a YAML-based configuration file that defines an automated process [1][2]. To be recognized and executed by GitHub, these files must meet the following requirements: Location: Workflow files must be stored in the.github/workflows directory at the root of your repository [1][2][3]. File Extensions: Files must use either the.yml or.yaml extension [2][3]. Functionality: Each workflow file defines one or more jobs that run in response to specific events (e.g., a push to the repository, a pull request, or a scheduled time) [1][4][5]. You may have multiple workflow files in the.github/workflows directory, each handling different automation tasks [1][4]. When an event triggers a workflow, GitHub scans this directory to identify and run the corresponding YAML files [1]. If a name is not explicitly defined within the YAML file using the name key, GitHub will use the file path as the display name in the repository's Actions tab [2][5].
Citations:
- 1: https://docs.github.com/actions/using-workflows/about-workflows
- 2: https://docs.github.com/actions/using-workflows/workflow-syntax-for-github-actions
- 3: https://docs.github.com/actions/get-started/quickstart
- 4: https://docs.github.com/articles/getting-started-with-github-actions
- 5: https://docs.github.com/en/actions/tutorials/create-an-example-workflow
🌐 Web query:
site:docs.github.com Actions workflow filenames must end with .yml or .yaml
💡 Result:
Yes, GitHub Actions workflow files must have either a.yml or.yaml file extension for GitHub to discover and run them [1][2]. These files must also be stored in the.github/workflows directory of your repository [1][2]. Similarly, if you are creating custom actions, their metadata files must also use the YAML syntax and be named either action.yml or action.yaml (with action.yml being the preferred format) [3][4].
Citations:
- 1: https://docs.github.com/actions/using-workflows/workflow-syntax-for-github-actions
- 2: https://docs.github.com/actions/get-started/quickstart
- 3: https://docs.github.com/actions/creating-actions/about-custom-actions
- 4: https://docs.github.com/en/actions/reference/workflows-and-actions/metadata-syntax
Rename this workflow file to release-tagged.yml or release-tagged.yaml. GitHub Actions only discovers workflows in .github/workflows when the file has a YAML extension, so this one will be ignored as-is.
🤖 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/release-tagged at line 1, The workflow is currently
defined in a file without a YAML extension, so GitHub Actions will not discover
it. Rename the workflow file that contains the Release job to use a valid
workflow extension such as release-tagged.yml or release-tagged.yaml, keeping
the workflow contents unchanged.
|
|
||
| on: | ||
| push: | ||
| branches: ["v[1-9]", next"] |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟡 Minor
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Locate the workflow file and inspect the relevant lines with numbers.
git ls-files .github/workflows/release-tagged
wc -l .github/workflows/release-tagged
sed -n '1,40p' .github/workflows/release-tagged | cat -n
# Read as data to spot YAML syntax issues around the branches filter.
python3 - <<'PY'
from pathlib import Path
p = Path('.github/workflows/release-tagged')
text = p.read_text()
for i, line in enumerate(text.splitlines(), 1):
if 'branches:' in line or 'next' in line:
print(f"{i}: {line}")
PYRepository: solidjs-community/solid-primitives
Length of output: 1273
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the workflow file around the reported line.
sed -n '1,20p' .github/workflows/release-tagged | cat -n
# Show the exact branch filter line with surrounding context.
python3 - <<'PY'
from pathlib import Path
p = Path('.github/workflows/release-tagged')
for i, line in enumerate(p.read_text().splitlines(), 1):
if 1 <= i <= 10:
print(f"{i}: {line}")
PYRepository: solidjs-community/solid-primitives
Length of output: 833
🏁 Script executed:
#!/bin/bash
set -euo pipefail
python3 - <<'PY'
snippet = 'branches: ["v[1-9]", next"]\n'
print(snippet)
try:
import yaml
data = yaml.safe_load(snippet)
print("PyYAML parsed:", data)
except Exception as e:
print("PyYAML error:", type(e).__name__, e)
PYRepository: solidjs-community/solid-primitives
Length of output: 250
🌐 Web query:
YAML plain scalar double quote valid in plain style next" flow sequence
💡 Result:
In YAML, a double quote character (") is not allowed inside a plain scalar if it occurs at the beginning of the string, as it is a reserved indicator [1][2][3]. However, if a double quote appears elsewhere in the string, it is generally treated as a literal character and does not require escaping, provided the string does not violate other plain scalar rules (such as starting with other special characters or containing restricted sequences) [4][2][5]. Regarding your query about whether this is valid next to a flow sequence: yes, a string containing a double quote can appear in a flow sequence (e.g., [item, "value with " quotes", another_item]) [2]. If the double quote is part of a plain scalar (unquoted) style, the YAML parser interprets it as literal text unless the position or context creates ambiguity [4][2][3]. Key constraints for plain scalars: - Cannot start with:!, @, #, %, &, *, |, >,,, {, }, [, ],?, ', ", a backtick, or whitespace [1][2]. - Cannot contain: the colon-space sequence (:) or the # character when it could be mistaken for a comment [1][6]. - Cannot end with: whitespace [1][3]. If your string contains double quotes and you find the plain style behavior ambiguous or restrictive, it is standard practice to switch to the double-quoted style, where double quotes must be escaped with a backslash (") [4][7][5].
Citations:
- 1: https://yamlscript.org/blog/2025-07-20/yaml-best-practices/
- 2: https://github.com/ActiveState/yaml-blog-post/blob/master/YAML-Like-a-Pro.md
- 3: https://stackoverflow.com/questions/19109912/do-i-need-quotes-for-strings-in-yaml
- 4: https://blogs.perl.org/users/tinita/2018/03/strings-in-yaml---to-quote-or-not-to-quote.html
- 5: https://www.yaml.info/learn/quote.html
- 6: https://yaml-multiline.info/
- 7: https://docs.octoprint.org/en/main/configuration/yaml.html
Fix the branch filter typo. next" is treated as a literal branch name, so pushes to next won’t match.
Suggested fix
- branches: ["v[1-9]", next"]
+ branches: ["v[1-9]", "next"]📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| branches: ["v[1-9]", next"] | |
| branches: ["v[1-9]", "next"] |
🤖 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/release-tagged at line 5, The branch filter in the release
workflow has a typo that prevents matching the intended next branch. Update the
branches list in the release-tagged workflow so the branch pattern is valid and
references the intended next branch correctly; verify the branch filter syntax
around the branches configuration so pushes to next are matched as expected.
| "measure": "node --import=@nothing-but/node-resolve-ts --experimental-transform-types ./scripts/measure.ts", | ||
| "version": "changeset version && pnpm i --no-frozen-lockfile && git add .", | ||
| "release": "pnpm build && changeset publish", | ||
| "release-tagged": "pnpm build && changeset publish --tag $(git branch --show-current)", |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf 'Repo root files of interest:\n'
git ls-files package.json .github/workflows/release-tagged* README.md
printf '\npackage.json excerpt:\n'
cat -n package.json | sed -n '25,45p'
printf '\nWorkflow excerpt:\n'
cat -n .github/workflows/release-tagged* | sed -n '1,220p'
printf '\nREADME refs to dist-tag/next:\n'
rg -n "dist-tag|next branch|release-tagged|changeset publish|release-tagged" README.md .github/workflows package.jsonRepository: solidjs-community/solid-primitives
Length of output: 3308
🏁 Script executed:
#!/bin/bash
set -euo pipefail
python3 - <<'PY'
import subprocess, os, textwrap, json, shlex, sys
# Probe GitHub Actions ref_name semantics from docs? Not external. We'll just inspect workflow env and package script usage.
PYRepository: solidjs-community/solid-primitives
Length of output: 172
🌐 Web query:
GitHub Actions checkout detached HEAD git branch --show-current empty github.ref_name ref_name docs
💡 Result:
When using actions/checkout in GitHub Actions, the repository is typically placed in a "detached HEAD" state by default [1][2][3]. This occurs because the action fetches and checks out the specific commit SHA associated with the workflow trigger (such as a pull request head or push commit) rather than checking out a local branch [4][5]. Because the repository is in a detached HEAD state, the command git branch --show-current returns an empty string [1]. This is standard Git behavior, as HEAD is pointing directly to a commit hash rather than a symbolic branch reference [1][2]. Regarding the behavior of GitHub Actions environment variables: - GITHUB_REF_NAME: This variable provides the branch or tag name that triggered the workflow (e.g., main, v1.0.0). It remains populated even when the local repository is in a detached HEAD state because it is provided by the GitHub Actions runner environment, not by the local Git repository state [6]. - Detached HEAD implications: While it may be unexpected, being in a detached HEAD state is not an error [1][2]. It is the intended default for Actions to ensure the runner is operating on the exact commit that triggered the workflow [4]. If your workflow requires a local branch to be checked out (for example, to perform Git operations that require a branch context), you can explicitly checkout the branch using the following steps: 1. Configure actions/checkout to fetch the necessary history (e.g., fetch-depth: 0) [7][8][9]. 2. Use a run step to create or check out the branch: run: git checkout -B ${{ github.head_ref || github.ref_name }} [8][9] This ensures that your local Git environment has a named branch reference instead of a detached HEAD [8][9].
Citations:
- 1: Git status should handle detached HEAD by showing the current commit MoonshotAI/kimi-code#566
- 2: https://oneuptime.com/blog/post/2026-01-24-git-detached-head-state/view
- 3: https://serverfault.com/questions/896297/jenkins-ci-and-git-plugin-detached-head-state-at-some-point
- 4: https://stackoverflow.com/questions/76535794/why-does-actions-checkout-fetch-the-latest-commit-right-after-cloning-the-reposi
- 5: https://opentestfactory.org/providers/actionprovider.html
- 6: https://github.com/orgs/community/discussions/64528
- 7: How to checkout current PR branch? actions/checkout#1108
- 8: About the example workflow to avoid detached head in github actions reg-viz/reg-suit#590
- 9: https://dev.to/martinratinaud/checkout-several-branches-in-github-actions-3nmc
Use the workflow ref name for the publish tag. git branch --show-current is empty on the detached checkout used by Actions, so changeset publish can receive an empty dist-tag. Pass ${{ github.ref_name }} (or an explicit RELEASE_TAG) into the publish step instead.
🤖 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 `@package.json` at line 34, The release-tagged publish command is using git
branch --show-current, which can be empty in detached GitHub Actions checkouts
and lead to an empty dist-tag. Update the release-tagged script in package.json
to use the workflow ref name instead, and wire the value in from github.ref_name
or a RELEASE_TAG environment variable so changeset publish always receives a
valid tag.
Deploying solid-primitives with
|
| Latest commit: |
b490f26
|
| Status: | 🚫 Build failed. |
2 participants
Releases from next and v[1-9] branch into a tag with the same name.
Summary by CodeRabbit
New Features
Chores