chore: add ready-to-use complete package as release assets - #131
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
❌ Deploy Preview for feeddony failed.
|
📝 WalkthroughWalkthroughChangesRelease artifact packaging
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant SemanticRelease
participant ExecPlugin
participant Repository
participant GitHubRelease
SemanticRelease->>ExecPlugin: Run prepareCmd
ExecPlugin->>Repository: Create versioned tar.gz and zip archives
SemanticRelease->>GitHubRelease: Pass generated assets
GitHubRelease->>Repository: Upload both archives
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 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 |
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 0 |
| Duplication | 0 |
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
| [ | ||
| "@semantic-release/exec", | ||
| { | ||
| "prepareCmd": "rm -f tt-rss-${nextRelease.version}-complete.tar.gz tt-rss-${nextRelease.version}-complete.zip && tar --exclude='.git' --exclude='.github' -czf tt-rss-${nextRelease.version}-complete.tar.gz . && zip -r tt-rss-${nextRelease.version}-complete.zip . -x '.git/*' -x '.github/*'" |
There was a problem hiding this comment.
⚠️ Bug: zip archive bundles the freshly-created tar.gz
The tar command runs first and writes tt-rss-${version}-complete.tar.gz into the current directory, then zip -r ... . archives . while only excluding .git/* and .github/*. Since the tar.gz now exists in the tree, the zip will contain a full copy of the complete tarball, roughly doubling the zip's size with redundant data. Exclude the tar.gz (and the zip itself) from the zip run, e.g. add -x 'tt-rss-*-complete.tar.gz' -x 'tt-rss-*-complete.zip', or build the zip before the tar.gz.
Was this helpful? React with 👍 / 👎
Code Review
|
| Auto-apply | Compact |
|
|
Important
Your trial ends in 7 days — upgrade now to keep code review, CI analysis, auto-apply, custom automations, and more.
Was this helpful? React with 👍 / 👎 | Gitar
|
|
Queued — the merge queue status continues in this comment ↓. |
Merge Queue Status
This pull request spent 10 seconds in the queue, including 1 second running CI. Required conditions to merge |
PR Summary by QodoAdd ready-to-use complete package archives as semantic-release assets
AI Description
Diagram
High-Level Assessment
Files changed (2)
|
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 @.releaserc.json:
- Around line 50-51: The release assets in the .releaserc configuration use
version templates in path, which must remain stable source paths. Update both
archive entries to use version-independent paths, and move the versioned
filenames using ${nextRelease.version} into their name fields while preserving
the existing labels.
🪄 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: 089762e1-3cb1-4de5-987f-83d6dc09eee1
📒 Files selected for processing (2)
.releaserc.jsonpackage.json
| { "path": "tt-rss-${nextRelease.version}-complete.tar.gz", "label": "Ready to use (tar.gz)" }, | ||
| { "path": "tt-rss-${nextRelease.version}-complete.zip", "label": "Ready to use (zip)" } |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== .releaserc.json relevant lines =="
sed -n '1,90p' .releaserc.json 2>/dev/null || true
echo
echo "== semantic-release github package references =="
rg -n '"`@semantic-release/github`"|semantic-release/github|assets\.path|assets\]|path.*name|label' -S package.json pnpm-lock.yaml package-lock.json yarn.lock .releaserc.json 2>/dev/null | head -n 120 || true
echo
echo "== installed library docs if available =="
node - <<'JS'
const fs = require('fs');
const path = require('path');
for (const candidates of [
['node_modules/@semantic-release/github/README.md','node_modules/@semantic-release/github/readme.md'],
['node_modules/@semantic-release/gitlab/README.md','node_modules/@semantic-release/gitlab/readme.md']
]) {
for (const p of candidates) {
if (fs.existsSync(p)) {
console.log(`--- ${p} ---`);
const lines = fs.readFileSync(p,'utf8').split(/\r?\n/);
lines.forEach((line, i) => {
if (/assets|path|name|label|glob|template|release assets/i.test(line)) {
console.log(`${i+1}: ${line}`);
}
});
break;
}
}
}
JSRepository: ashcoft/tt-rss-non-dockerize
Length of output: 14687
🌐 Web query:
@semantic-release/github assets path glob documentation path property glob
💡 Result:
In the @semantic-release/github plugin, the assets option is used to define files to upload to a GitHub release [1][2]. The assets option accepts either a glob (a string) or an array containing a mix of globs and objects [1][2]. When using an object within the assets array, the path property is required [1][2]. Its purpose is to specify a glob used to identify the files you wish to upload [1][2]. Key details regarding this configuration include: - Glob Flexibility: You can provide a single glob string (e.g., 'dist//.js') or an array of strings that will be globbed together (e.g., ['dist/', '!/.css']) [1][2]. - Object Properties: When using an object, the path property is mandatory [1][2]. You may optionally include a name property to specify the file name as it will appear on the GitHub release (defaulting to the file name extracted from the path) and a label property for a short description [1][2]. - Path Handling: It is important to note that GitHub releases do not support directory structures; they only handle files [3]. Therefore, if a glob matches files in different directories, the plugin will upload them, but their directory paths are not preserved in the release itself [3]. If multiple files resolved by a glob share the same filename, this will result in a conflict [3]. Using the object syntax with the name property allows you to explicitly rename files to ensure unique names on the GitHub release [1][4]. The generation of the name and label properties supports Lodash templates, allowing you to use variables such as ${nextRelease.gitTag} [1][4].
Citations:
- 1: https://github.com/semantic-release/github
- 2: https://registry.npmjs.org/@semantic-release/github
- 3: Glob in
assetsfield flattens paths... is this intentional? semantic-release/github#58 - 4: https://cdn.jsdelivr.net/npm/@semantic-release/github@12.0.9/README.md
🌐 Web query:
@semantic-release/github assets template path label name nextRelease version
💡 Result:
The @semantic-release/github plugin allows you to define asset names and labels using Lodash templates, which include access to the nextRelease version [1][2]. Key points regarding the configuration: 1. Template Availability: You can use the nextRelease object (as well as branch, lastRelease, and commits) within the name and label properties of your asset objects [1][3]. 2. Example Usage: To include the version tag in your asset name or label, you can use the following syntax [1][2]: { "path": "dist/MyLibrary.js", "name": "MyLibrary-${nextRelease.gitTag}.js", "label": "MyLibrary JS (${nextRelease.gitTag}) distribution" } 3. Path Limitation: Templates are not supported within the path property [4]. The path must be a valid glob to identify the files [1][3]. If you need a versioned filename in your release, you should use a static (unversioned) file name in the path and specify the desired versioned name using the name property as shown above [4]. When using the plugin, ensure your configuration is defined within the @semantic-release/github plugin options rather than at the top level to avoid conflicts with other plugins like @semantic-release/git that also use an assets option [5].
Citations:
- 1: https://github.com/semantic-release/github?tab=readme-ov-file
- 2: https://cdn.jsdelivr.net/npm/@semantic-release/github@12.0.9/README.md
- 3: https://npmx.dev/package/@semantic-release/github/v/12.0.8
- 4: Can I use the templates in asset's path config? semantic-release/github#274
- 5: assets option is ambiguous with git plugin assets option semantic-release/github#808
Use a static asset path.
path is a glob and templates are applied to name/label, so ${nextRelease.version} is interpreted as a literal filename pattern. This can miss the generated archives; keep the source asset path stable/version-independent and move the versioned GitHub asset filename to name.
🤖 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 @.releaserc.json around lines 50 - 51, The release assets in the .releaserc
configuration use version templates in path, which must remain stable source
paths. Update both archive entries to use version-independent paths, and move
the versioned filenames using ${nextRelease.version} into their name fields
while preserving the existing labels.
Code Review by Qodo
Context used✅ Compliance rules (platform):
11 rules 1. Lockfile missing new dependency
|
| "vue-eslint-parser": "^10.4.1", | ||
| "@semantic-release/exec": "^6.0.3" |
There was a problem hiding this comment.
1. Lockfile missing new dependency 🐞 Bug ≡ Correctness
package.json adds @semantic-release/exec but package-lock.json is not updated, so the Release workflow’s npm ci step is likely to fail before semantic-release runs. Even if install somehow proceeds, semantic-release won’t be able to load the configured @semantic-release/exec plugin without it being present in the lock-resolved install set.
Agent Prompt
## Issue description
`@semantic-release/exec` was added to `package.json` but the repo lockfile wasn’t updated. The release workflow uses `npm ci`, which requires `package.json` and `package-lock.json` to be in sync; otherwise the workflow will fail during dependency installation and releases will stop.
## Issue Context
- Release pipeline runs `npm ci`.
- `package-lock.json` currently lists other `@semantic-release/*` plugins but not `@semantic-release/exec`.
## Fix Focus Areas
- package.json[45-50]
- package-lock.json[1-45]
- .github/workflows/release.yml[20-31]
## Suggested fix
1. Regenerate the lockfile using npm (e.g., `npm install` or `npm install --package-lock-only`) so `@semantic-release/exec` is recorded.
2. Commit the updated `package-lock.json` (and ensure the chosen package manager/lockfile is the one used in CI).
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| "@semantic-release/exec", | ||
| { | ||
| "prepareCmd": "rm -f tt-rss-${nextRelease.version}-complete.tar.gz tt-rss-${nextRelease.version}-complete.zip && tar --exclude='.git' --exclude='.github' -czf tt-rss-${nextRelease.version}-complete.tar.gz . && zip -r tt-rss-${nextRelease.version}-complete.zip . -x '.git/*' -x '.github/*'" | ||
| } |
There was a problem hiding this comment.
2. Zip bundles generated tarball 🐞 Bug ≡ Correctness
The prepareCmd creates tt-rss-<version>-complete.tar.gz and then runs zip -r ... . without excluding the tarball, so the resulting “complete.zip” will also contain the “complete.tar.gz” inside it. This inflates the zip asset and produces unexpected release contents.
Agent Prompt
## Issue description
The zip step archives the entire working directory after the tarball has been created, but it only excludes `.git/*` and `.github/*`. As a result, the just-created `tt-rss-...-complete.tar.gz` will be included inside the zip.
## Issue Context
Current command order is: `tar ... -czf <tarball> . && zip -r <zip> . ...`.
## Fix Focus Areas
- .releaserc.json[40-44]
## Suggested fix
Pick one approach:
- Add explicit excludes to the zip command (at minimum for the tarball and the zip itself), e.g. exclude `tt-rss-*-complete.tar.gz` and `tt-rss-*-complete.zip`.
- Preferably, create artifacts in a separate output directory (e.g. `/tmp/release-assets`) and upload from there, so the archive inputs never contain the outputs.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| "@semantic-release/exec", | ||
| { | ||
| "prepareCmd": "rm -f tt-rss-${nextRelease.version}-complete.tar.gz tt-rss-${nextRelease.version}-complete.zip && tar --exclude='.git' --exclude='.github' -czf tt-rss-${nextRelease.version}-complete.tar.gz . && zip -r tt-rss-${nextRelease.version}-complete.zip . -x '.git/*' -x '.github/*'" | ||
| } |
There was a problem hiding this comment.
3. Tar output inside input tree 🐞 Bug ☼ Reliability
The tar command writes its output file into the same directory tree it is archiving (`-czf <archive> .`) and does not explicitly exclude the archive filename. This relies on tar implementation details (often skipping the archive implicitly) and can generate warnings or brittle behavior across environments.
Agent Prompt
## Issue description
The tarball is created in the directory being archived. Even if common tar implementations avoid self-including the output archive, this is brittle and can emit warnings or behave differently across environments.
## Issue Context
Current tar usage: `tar ... -czf tt-rss-${nextRelease.version}-complete.tar.gz .`.
## Fix Focus Areas
- .releaserc.json[40-44]
## Suggested fix
Use one of:
- Create archives in a separate output directory (recommended), and archive the source directory contents from outside.
- Or explicitly exclude the output filename from the tar input set, e.g. add `--exclude=./tt-rss-${nextRelease.version}-complete.tar.gz` (and similarly for the zip step if needed).
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Summary
Add pre-built complete package as release assets so users can download and extract to run immediately.
Changes
@semantic-release/execplugintt-rss-X.Y.Z-complete.tar.gzandtt-rss-X.Y.Z-complete.zipRelease Assets
What's Included
vendor/- PHP dependenciesnode_modules/- Node dependenciespnpm-lock.yaml- Locked versionsUsers can extract and run without
composer installorpnpm install.Summary by CodeRabbit