chore: new deploy flow#358
Conversation
📝 WalkthroughWalkthroughRemoves the branch-push ChangesDeploy & QA Workflow Replacement
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ 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: 2
🤖 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/deploy.yml:
- Around line 8-10: The workflow concurrency on the deploy job is cancelling
in-progress runs, which can interrupt a release after npm publishing has already
succeeded. Update the concurrency settings in the deploy workflow so tag-based
publish/release runs are not cancelled mid-flight, and keep the job that
publishes via npm and then creates the GitHub release protected from
duplicate-run cancellation; use the deploy workflow’s concurrency block to
locate the change.
- Around line 4-6: The deploy workflow tag filter is using regex-style syntax in
a GitHub Actions glob field, so the current pattern will not match normal
release tags. Update the `push.tags` filter in the deploy workflow to use a glob
pattern such as `v*.*.*` instead, and keep the version validation in the later
job step unchanged. Use the existing `push` trigger section in the workflow to
locate and adjust the tag matcher.
🪄 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
Run ID: 47f8518a-dfad-47e7-8347-78d3e1d09aad
📒 Files selected for processing (3)
.github/workflows/deploy.yml.github/workflows/publish.yml.github/workflows/qa.yaml
💤 Files with no reviewable changes (1)
- .github/workflows/publish.yml
| push: | ||
| tags: | ||
| - "v[0-9]+.[0-9]+.[0-9]+" |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n== Workflow snippet ==\n'
git ls-files .github/workflows/deploy.yml
wc -l .github/workflows/deploy.yml
sed -n '1,40p' .github/workflows/deploy.yml
printf '\n== Search for release/version tags and workflow docs references ==\n'
rg -n 'v\[0-9\]\+|tags:|push:' .github/workflows/deploy.yml .github -g '!**/*.png' -g '!**/*.jpg' -g '!**/*.svg' || trueRepository: ton-org/blueprint
Length of output: 1657
🌐 Web query:
GitHub Actions tag filters glob patterns regex quantifiers documentation refs tags pattern syntax
💡 Result:
GitHub Actions workflow triggers do not use full regular expressions (regex) [1]. Instead, they use a specific set of glob pattern syntax for tags (and branches) filters [2][3][4]. Key points regarding the pattern syntax: - Glob Patterns: The system supports standard glob characters, which are documented in the official GitHub Actions workflow syntax references [2][3][4]. - Supported Characters: - *: Matches zero or more characters, but does not match the forward slash (/) [4][5]. - ``: Matches zero or more of any character, including slashes [4][5]. - ?: Matches zero or one of the preceding character (not a standard wildcard for "any single character" in this context) [5]. - `+`: Matches one or more of the preceding character [5]. - `[...]`: Matches one alphanumeric character listed in the brackets or included in ranges (e.g., `[a-z0-9]`) [5]. - `!`: When placed at the start of a pattern, it negates the pattern, excluding the ref [4][6][5]. - YAML Special Characters: Characters like `*`, `[`, and `!` are special in YAML [7][5]. If a pattern begins with one of these, you must enclose the entire pattern in quotes (e.g., `'*pattern'`) to prevent YAML parsing errors [4][7][5]. - Literal Matches: If you need to match a character literally that is otherwise used as a special pattern character, you must escape it with a backslash (``) [2][3][4]. - Exclusion: You cannot use both inclusive (`tags`) and exclusive (`tags-ignore`) keywords for the same event [2][3]. To both include and exclude, use the `tags` keyword with the `!` operator for exclusions [2][6]. Order matters: matching a positive pattern after a negative one will re-include the ref [6].
Citations:
- 1: https://stackoverflow.com/questions/68078004/why-doesnt-my-github-action-trigger-on-a-regex-tag
- 2: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax
- 3: https://docs.github.com/actions/using-workflows/workflow-syntax-for-github-actions
- 4: https://github.com/github/docs/blob/main/content/actions/reference/workflows-and-actions/workflow-syntax.md
- 5: https://github.com/anttiharju/compare-changes/blob/d9671ec54831fa88d07712557052dcb14f938e6f/docs/github/workflow_syntax.md
- 6: https://stackoverflow.com/questions/76612101/match-tags-in-github-action
- 7: Note on the use of square brackets in GitHub Actions workflows filter patterns github/docs#18969
🌐 Web query:
site:docs.github.com GitHub Actions workflow syntax + one or more preceding character tags pattern matching
💡 Result:
In GitHub Actions, workflow triggers for push events can be filtered using the tags keyword, which supports glob pattern matching to target specific tags [1][2]. Key points for tags pattern matching: Pattern Support: The tags keyword accepts glob patterns including characters like ,, +,?, and! [1][2]. The wildcard, for instance, can be used to match any sequence of characters within a tag name (e.g., v1.) [3]. The! character is used for exclusion; however, if you use! to exclude a tag, you must also define at least one inclusion pattern within the same tags block [1][4]. Constraint: You cannot use the tags and tags-ignore keywords simultaneously for the same event in a single workflow [1][2]. If you need to both include and exclude tags, use only the tags keyword with the! operator [1][5]. Literal Matching: If your tag names contain any of the special glob characters (,, +,?,!), you must escape them with a backslash () to perform a literal match [1][6]. Example Configuration: on: push: tags: - v1.* - '!v1.0-beta*' # Matches all v1. tags except those starting with v1.0-beta - release- When using these filters, the workflow will trigger only when a push event involves a tag that matches the inclusion criteria (after accounting for any exclusions) [1][2].
Citations:
- 1: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax
- 2: https://docs.github.com/actions/using-workflows/triggering-a-workflow
- 3: https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows
- 4: https://docs.github.com/en/enterprise-cloud@latest/actions/reference/workflows-and-actions/workflow-syntax
- 5: https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow
- 6: https://docs.github.com/actions/using-workflows/workflow-syntax-for-github-actions
🌐 Web query:
site:docs.github.com/actions workflow syntax tags glob pattern [0-9]+ semver
💡 Result:
GitHub Actions workflow tag filters use glob patterns to match tag names, but they do not natively support Semantic Versioning (SemVer) ranges or advanced regex-style character classes like [0-9]+ [1]. Key points regarding tag filtering in GitHub Actions: 1. Supported Patterns: The on.push.tags and on.push.tags-ignore keywords support standard glob patterns, including the following wildcards [1]: * *: Matches zero or more characters, excluding the directory separator. *: Matches zero or more directories or characters. *?: Matches exactly one character. * +: Used for pattern matching within the context of the supported glob library. !: Used to exclude specific patterns. 2. Lack of Native SemVer/Regex Support: The system interprets these filters as glob patterns, not as Semantic Versioning ranges or regular expressions. Consequently, a syntax like [0-9]+ is not treated as a numeric character class. If you use square brackets in a pattern, they are generally interpreted as literal characters rather than regex quantifiers, unless specifically handled by the underlying glob implementation as a character set (which is not standard across all GitHub Actions glob contexts). 3. Handling Special Characters: If a tag name actually contains characters used by the glob syntax (e.g., ,?, or!), you must escape them with a backslash () to match them literally [1]. 4. Workaround: Since native SemVer ranges are not supported in the workflow YAML trigger filters, the common approach is to use a broad glob pattern (e.g., v) to trigger the workflow on all version tags, and then perform specific SemVer validation or range checking using a conditional expression (the if keyword) or a dedicated step within the job itself. Example of a broad trigger: on: push: tags: - 'v' # Triggers on all tags starting with 'v' Conditional logic inside the job: jobs: build: if: startsWith(github.ref, 'refs/tags/v1.') runs-on: ubuntu-latest steps:..., top_results=[1]}];]
Citations:
🌐 Web query:
site:docs.github.com/actions '+' pattern literal workflow syntax glob
💡 Result:
In the context of GitHub Actions workflow syntax, the plus sign (+) is treated as a special glob pattern character when used in filters for branches or tags (e.g., in on.<push|pull_request>.branches or tags) [1][2]. Because it is a wildcard character used to match branch or tag names, it is not interpreted literally. To use a plus sign as a literal character in these patterns, you must escape it using a backslash () [1][2]. For example, if you have a branch named "feature+test" and want to match it specifically, you would define the pattern as: branches: - 'feature+test' If the plus sign is not escaped, the system will attempt to treat it as part of the glob matching logic rather than as the literal character '+'. This escaping requirement applies to other special glob characters as well, such as *,,?, and! [1][2].
Citations:
- 1: https://docs.github.com/actions/using-workflows/workflow-syntax-for-github-actions
- 2: https://docs.github.com/actions/using-workflows/triggering-a-workflow
🌐 Web query:
site:docs.github.com/actions tags filter plus literal character github actions workflow syntax
💡 Result:
In GitHub Actions workflows, the tags filter supports glob patterns by default, which means special characters like ,, +,?, and! are treated as functional operators rather than literal characters [1][2]. To use a literal character that is also a glob special character (such as matching a tag named v1 where the * is part of the name rather than a wildcard), you must escape the character using a backslash () [1][2]. For example, to match a tag named v1* exactly, your configuration would look like this: on: push: tags: - v1* This ensures the asterisk is treated as a literal part of the tag name rather than a wildcard operator [1][2].
Citations:
- 1: https://docs.github.com/actions/using-workflows/workflow-syntax-for-github-actions
- 2: https://docs.github.com/actions/using-workflows/triggering-a-workflow
🌐 Web query:
site:github.com/github/docs workflow syntax tags pattern plus literal
💡 Result:
In GitHub Actions workflows, the tags keyword is used under the on.push event to filter which pushed tags trigger a workflow run [1]. When defining these filters, you can use either literal strings for exact matches or glob patterns to match multiple tags [2][3]. Key considerations for tag pattern syntax include: Pattern Matching: You can use wildcards such as * (matches zero or more characters, excluding slashes) and (matches zero or more characters, including slashes) to create flexible patterns [2]. Literal Matches: If a tag name contains characters that are also used as glob wildcards (like *, [, or!), you must escape them with a backslash () if you intend for them to be treated as literals [3]. YAML Special Characters: Certain characters, including , [, and!, have special meaning in YAML [2][3]. If your pattern begins with any of these characters, you must enclose the entire pattern in quotes (e.g., '' or '[v1]') to prevent YAML parsing errors [2][3]. Flow Sequences: If you are using a YAML flow sequence (e.g., - [ 'tag1', 'tag2' ]) and the pattern contains square brackets, the entire pattern must be enclosed in quotes to ensure correct interpretation [4][3]. For example, to match any tag starting with v1., you would use: on: push: tags: - 'v1.' To match a specific tag that contains special characters literally, escape them: on: push: tags: - 'v1.0[beta]'
Citations:
- 1: https://github.com/github/docs/blob/main/content/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows.md
- 2: https://github.com/github/docs/blob/main/content/actions/reference/workflows-and-actions/workflow-syntax.md
- 3: Note on the use of square brackets in GitHub Actions workflows filter patterns github/docs#18969
- 4: Note on the use of square brackets in GitHub Actions workflows filter patterns github/docs#18970
Fix the tag filter; it is using regex syntax in a glob field.
GitHub Actions tags filters use glob matching, so v[0-9]+.[0-9]+.[0-9]+ won’t match normal release tags like v0.44.2. Use a glob such as v*.*.* instead; the version is already checked later in the job.
Suggested fix
on:
push:
tags:
- - "v[0-9]+.[0-9]+.[0-9]+"
+ - "v*.*.*"📝 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.
| push: | |
| tags: | |
| - "v[0-9]+.[0-9]+.[0-9]+" | |
| on: | |
| push: | |
| tags: | |
| - "v*.*.*" |
🤖 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/deploy.yml around lines 4 - 6, The deploy workflow tag
filter is using regex-style syntax in a GitHub Actions glob field, so the
current pattern will not match normal release tags. Update the `push.tags`
filter in the deploy workflow to use a glob pattern such as `v*.*.*` instead,
and keep the version validation in the later job step unchanged. Use the
existing `push` trigger section in the workflow to locate and adjust the tag
matcher.
| concurrency: | ||
| group: ${{ github.workflow }}-${{ github.ref }} | ||
| cancel-in-progress: true |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Do not cancel in-progress runs around npm publish.
This workflow publishes to npm before creating the GitHub release. If a second run for the same tag cancels the first after npm publish succeeds, the retry will fail on the already-published version and the release step never runs, leaving npm and GitHub out of sync.
Suggested fix
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
- cancel-in-progress: true
+ cancel-in-progress: falseAlso applies to: 58-59
🤖 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/deploy.yml around lines 8 - 10, The workflow concurrency
on the deploy job is cancelling in-progress runs, which can interrupt a release
after npm publishing has already succeeded. Update the concurrency settings in
the deploy workflow so tag-based publish/release runs are not cancelled
mid-flight, and keep the job that publishes via npm and then creates the GitHub
release protected from duplicate-run cancellation; use the deploy workflow’s
concurrency block to locate the change.
2 participants
Issue
Closes #
Checklist
Please ensure the following items are completed before requesting review:
CHANGELOG.mdwith relevant changesREADME.mdyarn test)yarn lint)Summary by CodeRabbit