Skip to content

chore: add ready-to-use complete package as release assets - #131

Merged
mergify[bot] merged 3 commits into
mainfrom
add-release-assets
Jul 25, 2026
Merged

chore: add ready-to-use complete package as release assets#131
mergify[bot] merged 3 commits into
mainfrom
add-release-assets

Conversation

@ashcoft

@ashcoft ashcoft commented Jul 25, 2026

Copy link
Copy Markdown
Owner

Summary

Add pre-built complete package as release assets so users can download and extract to run immediately.

Changes

  • Add @semantic-release/exec plugin
  • Create complete package during release: tt-rss-X.Y.Z-complete.tar.gz and tt-rss-X.Y.Z-complete.zip
  • Attach both as release assets

Release Assets

Asset Description
Source code (zip) GitHub default
Source code (tar.gz) GitHub default
tt-rss-X.Y.Z-complete.tar.gz Complete package (tar.gz)
tt-rss-X.Y.Z-complete.zip Complete package (zip)

What's Included

  • Source code
  • vendor/ - PHP dependencies
  • node_modules/ - Node dependencies
  • pnpm-lock.yaml - Locked versions

Users can extract and run without composer install or pnpm install.

Summary by CodeRabbit

  • New Features
    • Release downloads now include downloadable TAR.GZ and ZIP archive packages.
    • Release pages provide clearly labeled links for each archive format.

@vercel

vercel Bot commented Jul 25, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
tt-rss-non-dockerize Error Error Jul 25, 2026 2:59am

@netlify

netlify Bot commented Jul 25, 2026

Copy link
Copy Markdown

Deploy Preview for feeddony failed.

Name Link
🔨 Latest commit 5189262
🔍 Latest deploy log https://app.netlify.com/projects/feeddony/deploys/6a642694f0843a000879c0fb

@coderabbitai

coderabbitai Bot commented Jul 25, 2026

Copy link
Copy Markdown

Review Change Stack

📝 Walkthrough

Walkthrough

Changes

Release artifact packaging

Layer / File(s) Summary
Archive generation and release upload
.releaserc.json, package.json
Adds the semantic-release exec plugin, generates versioned tar.gz and zip archives excluding .git and .github, and configures GitHub release uploads for both artifacts.

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
Loading

Suggested reviewers: openhands-agent

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly summarizes the main change: adding complete release assets.
Description check ✅ Passed The description covers the change, motivation, assets, and contents, but omits testing and checklist sections from the template.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch add-release-assets

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@codacy-production

Copy link
Copy Markdown

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity · 0 duplication

Metric Results
Complexity 0
Duplication 0

View in Codacy

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.

Comment thread .releaserc.json
[
"@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/*'"

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

⚠️ 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 👍 / 👎

@gitar-bot

gitar-bot Bot commented Jul 25, 2026

Copy link
Copy Markdown
Code Review ⚠️ Changes requested 0 resolved / 1 findings

Adds @semantic-release/exec to bundle source code, vendor, and node_modules into a release asset, but the zip archive incorrectly includes the newly created tar.gz file.

⚠️ Bug: zip archive bundles the freshly-created tar.gz

📄 .releaserc.json:43

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.

🤖 Prompt for agents
Code Review: Adds `@semantic-release/exec` to bundle source code, `vendor`, and `node_modules` into a release asset, but the zip archive incorrectly includes the newly created tar.gz file.

1. ⚠️ Bug: zip archive bundles the freshly-created tar.gz
   Files: .releaserc.json:43

   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.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Auto-apply Compact
gitar auto-apply:on         
gitar display:verbose         

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

@sonarqubecloud

Copy link
Copy Markdown

@ashcoft ashcoft changed the title chore: add vendor and node_modules tarballs as release assets chore: add ready-to-use complete package as release assets Jul 25, 2026
@ashcoft
ashcoft marked this pull request as ready for review July 25, 2026 03:01
@mergify

mergify Bot commented Jul 25, 2026

Copy link
Copy Markdown

Queued — the merge queue status continues in this comment ↓.

@mergify

mergify Bot commented Jul 25, 2026

Copy link
Copy Markdown

Merge Queue Status

  • Entered queue2026-07-25 03:02 UTC · Rule: default · triggered by @ashcoft with the merge queue checkbox
  • Checks skipped · PR is already up-to-date
  • Merged2026-07-25 03:03 UTC · at 51892623c49a916d69fec45295eb79d322eebdc9

This pull request spent 10 seconds in the queue, including 1 second running CI.

Required conditions to merge

@mergify mergify Bot added the queued label Jul 25, 2026
@mergify
mergify Bot merged commit b706c9b into main Jul 25, 2026
20 of 26 checks passed
@qodo-code-review

Copy link
Copy Markdown

PR Summary by Qodo

Add ready-to-use complete package archives as semantic-release assets

✨ Enhancement ⚙️ Configuration changes 🕐 10-20 Minutes

Grey Divider

AI Description

• Build “complete” release archives (tar.gz + zip) during semantic-release.
• Exclude repo metadata directories from the packaged artifacts.
• Upload the generated archives as GitHub Release assets for instant download/run.
Diagram

graph TD
  CI["Release CI"] --> SR["semantic-release"] --> Exec["@semantic-release/exec"] --> Art[("Complete archives")]
  Art --> GH{{"GitHub Release"}}

  subgraph Legend
    direction LR
    _svc[Service] ~~~ _artifact[(Artifact)] ~~~ _ext{{External}}
  end
Loading
High-Level Assessment

The following are alternative approaches to this PR:

1. Build artifacts in CI workflow and upload via GitHub Actions
  • ➕ Keeps release packaging logic in a dedicated CI YAML with clearer scripting and caching
  • ➕ Easier to run packaging in a clean environment (avoid accidentally bundling local/untracked files)
  • ➖ Splits release behavior across semantic-release config and CI workflow
  • ➖ More moving parts to keep version/asset naming consistent with semantic-release
2. Use a dedicated packaging script (e.g., scripts/build-release-archives.sh) invoked by exec
  • ➕ Improves readability and maintainability vs a long one-liner in JSON
  • ➕ Easier to test locally and extend (additional excludes, checks, reproducible builds)
  • ➖ Adds a new script file to maintain
  • ➖ Still relies on @semantic-release/exec (same plugin footprint)

Recommendation: The chosen semantic-release exec approach is reasonable for a small repo and keeps asset generation tied to the release lifecycle. Consider moving the long prepareCmd into a versioned script if the packaging rules grow (more excludes, validation, reproducibility), but otherwise this is an appropriate minimal solution.

Files changed (2) +12 / -2

Other (2) +12 / -2
.releaserc.jsonGenerate complete archives and publish them as GitHub release assets +10/-1

Generate complete archives and publish them as GitHub release assets

• Adds @semantic-release/exec to build versioned “complete” tar.gz/zip archives during the prepare phase, excluding .git and .github. Configures @semantic-release/github to upload both generated archives as labeled release assets.

.releaserc.json

package.jsonAdd @semantic-release/exec dependency for release-time packaging +2/-1

Add @semantic-release/exec dependency for release-time packaging

• Adds @semantic-release/exec to devDependencies so semantic-release can run the prepare command that builds the complete release archives.

package.json

@mergify mergify Bot removed the queued label Jul 25, 2026

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

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

📥 Commits

Reviewing files that changed from the base of the PR and between 0eac24a and 5189262.

📒 Files selected for processing (2)
  • .releaserc.json
  • package.json

Comment thread .releaserc.json
Comment on lines +50 to +51
{ "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)" }

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

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;
    }
  }
}
JS

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


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


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.

@qodo-code-review

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (0) 📜 Skill insights (0)

Context used
✅ Compliance rules (platform): 11 rules

Grey Divider


Action required

1. Lockfile missing new dependency 🐞 Bug ≡ Correctness
Description
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.
Code

package.json[R48-49]

+    "vue-eslint-parser": "^10.4.1",
+    "@semantic-release/exec": "^6.0.3"
Relevance

⭐⭐⭐ High

Repo has fixed npm ci lockfile mismatches before; adding dependency without updating package-lock
will be corrected.

PR-#13
PR-#109

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The release workflow installs dependencies using npm ci, but the lockfile’s devDependencies list
does not include the newly added @semantic-release/exec, indicating the lockfile is out of sync
with package.json and can break the install step required for release.

package.json[22-50]
package-lock.json[1-45]
.github/workflows/release.yml[20-31]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## 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



Remediation recommended

2. Zip bundles generated tarball 🐞 Bug ≡ Correctness
Description
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.
Code

.releaserc.json[R41-44]

+      "@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/*'"
+      }
Relevance

⭐⭐⭐ High

Prior release packaging wrote archives to dist to avoid self-inclusion; likely will exclude tarball
from zip.

PR-#16

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The prepare command explicitly creates the tar.gz first, then zips . while only excluding .git/*
and .github/*, so the tarball is eligible to be included in the zip contents.

.releaserc.json[40-55]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## 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


3. Tar output inside input tree 🐞 Bug ☼ Reliability
Description
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.
Code

.releaserc.json[R41-44]

+      "@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/*'"
+      }
Relevance

⭐⭐⭐ High

Repo previously generated tarball under dist instead of archiving output-in-tree; will likely adjust
for robustness.

PR-#16

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The configured tar invocation archives . while writing the tar.gz into the current directory, and
no exclusion is specified for the output artifact itself.

.releaserc.json[40-44]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## 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


Grey Divider

Qodo Logo

Comment thread package.json
Comment on lines +48 to +49
"vue-eslint-parser": "^10.4.1",
"@semantic-release/exec": "^6.0.3"

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Action required

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

Comment thread .releaserc.json
Comment on lines +41 to +44
"@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/*'"
}

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Remediation recommended

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

Comment thread .releaserc.json
Comment on lines +41 to +44
"@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/*'"
}

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Remediation recommended

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants