Skip to content

chore: new deploy flow #358

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Danil42Russia merged 1 commit into from
Jun 30, 2026
+82 −68
Merged

chore: new deploy flow #358

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
80 changes: 80 additions & 0 deletions .github/workflows/deploy.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,80 @@
name: Publish to NPM

on:
push:
tags:
- "v[0-9]+.[0-9]+.[0-9]+"
Comment on lines +4 to +6

@coderabbitai coderabbitai Bot Jun 30, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 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' || true

Repository: 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:

🌐 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:

🌐 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:

🌐 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:

🌐 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:

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.

Suggested change
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
Comment on lines +8 to +10

@coderabbitai coderabbitai Bot Jun 30, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🗄️ 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: false

Also 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.


permissions: {}

jobs:
publish:
name: Publish
runs-on: ubuntu-latest
environment: deploy
if: github.repository == 'ton-org/blueprint'

permissions:
contents: read
id-token: write # required for npm provenance when publishing with trusted publishing.

steps:
- name: Fetch Sources
uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
with:
persist-credentials: false

- name: Check package version
# language=Bash
run: |
package_version="$(jq -r .version package.json)"
tag_version="${GITHUB_REF_NAME#v}"

if [ "$tag_version" != "$package_version" ]; then
echo "::error title=Version mismatch::package.json(version) '${package_version}' does not match tag '${tag_version}'"
exit 1
fi

- name: Enable Corepack
run: corepack enable

- name: Setup Node
uses: actions/setup-node@48b55a011bda9f5d6aeb4c2d9c7362e8dae4041e # v6.4.0
with:
node-version: "24"
registry-url: "https://registry.npmjs.org"
package-manager-cache: false

- name: Install dependencies
run: yarn install --immutable --check-cache --check-resolutions

- name: Build
run: yarn run build

- name: Publish
run: npm publish --access public

release:
name: Create GitHub Release
runs-on: ubuntu-latest
needs: publish
if: github.repository == 'ton-org/blueprint'

permissions:
contents: write # required to create the GitHub Release for the published tag.

steps:
- name: Create GitHub Release
env:
GH_TOKEN: ${{ github.token }}
# language=Bash
run: |
gh release create "$GITHUB_REF_NAME" \
--repo "$GITHUB_REPOSITORY" \
--title "$GITHUB_REF_NAME" \
--generate-notes \
--verify-tag
63 changes: 0 additions & 63 deletions .github/workflows/publish.yml
View file
Open in desktop

This file was deleted.

7 changes: 2 additions & 5 deletions .github/workflows/qa.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,8 +9,7 @@ on:
- '*.md'
- '*.svg'
branches:
- main
- develop
- master
pull_request:
paths-ignore:
- '.github/workflows/publish.yml'
Expand All @@ -19,9 +18,7 @@ on:
- '*.md'
- '*.svg'
branches:
- main
- develop

- master
jobs:
lint:
name: Lint
Expand Down
Loading