chore(release): introduce semver versioning (0.7.0) — release-please + admin badge + Sentry - #152
Conversation
Canonical version in package.json (0.1.0 -> 0.7.0), inlined at build as NEXT_PUBLIC_APP_VERSION (+ best-effort NEXT_PUBLIC_GIT_SHA) and surfaced in the admin header badge and as the Sentry release (src/lib/sentry-options.ts). release-please (.github/workflows/release-please.yml) automates bumps from Conventional Commits (feat->minor, fix->patch); .release-please-manifest.json bootstraps the 0.7.0 baseline. See AGENTS.md § Versioning. Post-merge: create the v0.7.0 GitHub Release at the merged commit so release-please treats 0.7.0 as the last release. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
ceramics-drop | 6502c0b | Jul 16 2026, 08:23 AM |
📝 Walkthrough
WalkthroughDodano automatyzację release-please oraz ustanowiono ChangesWersjonowanie i release’y
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant ReleasePlease as release-please
participant PackageJson as package.json
participant NextConfig as next.config.ts
participant Admin as panel admina
participant Sentry as Sentry
ReleasePlease->>PackageJson: aktualizacja wersji w release PR
PackageJson->>NextConfig: odczyt version podczas builda
NextConfig->>Admin: NEXT_PUBLIC_APP_VERSION i NEXT_PUBLIC_GIT_SHA
NextConfig->>Sentry: release.name = packageJson.version
Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
Warning Review ran into problems🔥 ProblemsThese MCP integrations need to be re-authenticated in the Integrations settings: Notion 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-please.yml:
- Around line 12-14: Add the missing issues: write permission to the
workflow-level permissions block in release-please.yml, alongside contents and
pull-requests, so release-please-action can manage release PR issues and labels.
- Around line 8-10: Dodaj sekcję concurrency do workflow release-please z grupą
identyfikującą jego uruchomienia oraz ustawieniem cancel-in-progress: false, aby
kolejne uruchomienia były kolejkowane zamiast anulować lub wykonywać się
równolegle. Zachowaj istniejący trigger push dla gałęzi main.
- Around line 20-24: Remove the release-type input from the release-please
action configuration in the workflow, and add the equivalent release-type
setting to release-please-config.json so the manifest configuration controls the
release type.
🪄 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: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 63588d15-c945-4fc8-98a7-e0fef86e616b
📒 Files selected for processing (8)
.github/workflows/release-please.yml.release-please-manifest.jsonAGENTS.mdnext.config.tspackage.jsonsrc/app/admin/layout.tsxsrc/lib/sentry-options.tssrc/styles/admin.css
📜 Review details
⏰ Context from checks skipped due to timeout. (3)
- GitHub Check: Playwright
@cispecs - GitHub Check: Lint · Typecheck · Unit · Build
- GitHub Check: Workers Builds: ceramics-drop
🧰 Additional context used
📓 Path-based instructions (6)
src/app/admin/**
📄 CodeRabbit inference engine (.cursor/rules/orders-cli.mdc)
Prefer the orders CLI over the gated
/adminUI when performing admin mutations or inspecting order, inventory, or fulfilment state.
Files:
src/app/admin/layout.tsx
src/app/admin/**/*.tsx
📄 CodeRabbit inference engine (AGENTS.md)
Keep the admin UI outside the
[locale]route tree and protected by the production Cloudflare Access gate.
Files:
src/app/admin/layout.tsx
src/**/*.{ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
src/**/*.{ts,tsx}: Import localizedLinkanduseRouterfromsrc/i18n/navigation.ts, not directly from Next.js, so locale routing is preserved.
Analytics ecommerce values must use major currency units, while checkout and Stripe amounts use integer minor units; purchase events must use the deterministicpurchase-<payment_intent_id>event ID.
Files:
src/app/admin/layout.tsxsrc/lib/sentry-options.ts
src/**/*.{tsx,css}
📄 CodeRabbit inference engine (AGENTS.md)
src/**/*.{tsx,css}: Default to server components and add'use client'only when state, hooks, or browser APIs require it; never expose secrets to client components.
Use native product-image rendering withsrcSet()fromsrc/lib/images.ts; product photos must preserve their natural ratio and must not be cropped.
Files:
src/app/admin/layout.tsxsrc/styles/admin.css
src/**/*.{css,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
Use token-driven plain CSS from
src/styles/tokens.cssand colocated CSS files; do not introduce CSS-in-JS.
Files:
src/app/admin/layout.tsxsrc/styles/admin.css
package.json
📄 CodeRabbit inference engine (CLAUDE.md)
Keep the build command as
next build --webpack; do not add--turboor switch the project to Turbopack.
package.json: The production build must remainnext build --webpack; do not add or recommend Turbopack because OpenNext cannot load its chunks on Workers.
Treatpackage.jsonversionas the sole canonical version source; releases are automated by release-please using Conventional Commits.
Files:
package.json
🧠 Learnings (5)
📓 Common learnings
Learnt from: CR
Repo: konradciok/ceramics-drop
Timestamp: 2026-07-16T08:24:19.021Z
Learning: Use the repository commands and documented CLI workflows for development, testing, deployment, order operations, and Prodigi operations rather than ad-hoc alternatives.
📚 Learning: 2026-06-08T11:54:20.821Z
Learnt from: konradciok
Repo: konradciok/ceramics-drop PR: 38
File: docs/superpowers/plans/2026-06-08-go-to-market-execution.md:652-652
Timestamp: 2026-06-08T11:54:20.821Z
Learning: In this repo, build production URLs (e.g., in `src/lib/email.ts` and any other code that needs the site’s base URL) by importing and using `SITE_URL` from `@/lib/site`. Avoid hardcoding the base domain (e.g., `anna-ciok.studio`) in production code; use `SITE_URL` instead so URLs stay consistent across environments. In plan/docs markdown snippets, do not flag hardcoded `anna-ciok.studio` domains as a code issue when they are clearly illustrative and the real production implementation already uses the `SITE_URL` abstraction.
Applied to files:
src/app/admin/layout.tsxsrc/lib/sentry-options.tsAGENTS.mdnext.config.ts
📚 Learning: 2026-07-05T18:16:20.705Z
Learnt from: konradciok
Repo: konradciok/ceramics-drop PR: 104
File: src/app/admin/packing-ui.tsx:0-0
Timestamp: 2026-07-05T18:16:20.705Z
Learning: In this repo’s admin surface (files under src/app/admin/**, e.g., admin operator tooling that is intentionally Polish-only), do not use i18n helpers like getTranslations() (server) or useTranslations() (client) for UI strings. The getTranslations()/useTranslations i18n guideline is intended for the customer-facing 5-locale storefront only, so admin-only files like src/app/admin/packing-ui.tsx should keep strings Polish-only and avoid introducing translations.
Applied to files:
src/app/admin/layout.tsx
📚 Learning: 2026-06-04T12:32:59.822Z
Learnt from: konradciok
Repo: konradciok/ceramics-drop PR: 12
File: src/styles/tokens.css:13-15
Timestamp: 2026-06-04T12:32:59.822Z
Learning: In this repository’s CSS, follow the existing convention of quoting all `font-family` names (e.g., `font-family: 'Helvetica Neue', 'Futura BT', 'Jost';`). Since linting here is ESLint-only (no Stylelint enforcement), reviewers should not recommend removing these quotes for `font-family` values; preserve the quoted form to match the project’s style.
Applied to files:
src/styles/admin.css
📚 Learning: 2026-06-04T12:33:00.634Z
Learnt from: konradciok
Repo: konradciok/ceramics-drop PR: 12
File: src/styles/fonts.css:11-11
Timestamp: 2026-06-04T12:33:00.634Z
Learning: In this Next.js/CSS codebase, follow the established convention: always quote font-family names in CSS `font-family` declarations, even for single-word fonts (e.g., `font-family: 'Jost';`, `font-family: 'Helvetica Neue';`). When reviewing, do not suggest removing quotes for single-word `font-family` values just because Stylelint isn’t configured (ESLint-only linting).
Applied to files:
src/styles/admin.css
🪛 LanguageTool
AGENTS.md
[uncategorized] ~200-~200: The official name of this software platform is spelled with a capital “H”.
Context: ...ps are automated by release-please (.github/workflows/release-please.yml) from Con...
(GITHUB)
🪛 zizmor (1.26.1)
.github/workflows/release-please.yml
[error] 13-13: overly broad permissions (excessive-permissions): contents: write is overly broad at the workflow level
(excessive-permissions)
[error] 14-14: overly broad permissions (excessive-permissions): pull-requests: write is overly broad at the workflow level
(excessive-permissions)
[warning] 13-13: permissions without explanatory comments (undocumented-permissions): needs an explanatory comment
(undocumented-permissions)
[info] 17-17: workflow or action definition without a name (anonymous-definition): this job
(anonymous-definition)
[warning] 8-10: insufficient job-level concurrency limits (concurrency-limits): workflow is missing concurrency setting
(concurrency-limits)
🔍 Remote MCP Context7
Extra review context
-
In Next.js, values added via
next.config.tsenvare build-time inlined into the client bundle; theNEXT_PUBLIC_prefix only matters for variables coming fromprocess.env/.env, not fornext.configenventries. So the newNEXT_PUBLIC_APP_VERSIONandNEXT_PUBLIC_GIT_SHAwill be publicly available client-side as compiled constants. -
For release-please manifest mode,
.release-please-manifest.jsonis the source of truth for the last released version; for a single-component repo the key is.. The manifest must exist on the target branch tip and is updated after each release. Bootstrapping can create it, and the default--initial-versionis0.0.0unless overridden. -
Release Please docs say manifest mode is now the default for the action, and advanced setups can specify
config-fileandmanifest-file. The docs also note that if you want manifest behavior, you should not setrelease-typeto something else. -
Sentry docs say the SDK
releasevalue must match the release name used during source map upload; if bundler plugins are involved, theirrelease.namemust matchSentry.init()’sreleaseexactly. This makes the PR’s use of the package version as the shared release identifier important.
🔇 Additional comments (9)
package.json (1)
3-3: LGTM!next.config.ts (3)
12-19: 🗄️ Data Integrity & IntegrationZweryfikuj dostępność metadanych Git w produkcyjnym builderze.
Przy błędzie
git rev-parsewartość staje siędev. Jeśli Workers Builds buduje bez katalogu.git, wszystkie produkcyjne wdrożenia utracą korelację z konkretnym commitem. Potwierdź dostępność metadanych albo użyj udokumentowanego SHA z CI jako źródła podstawowego.
21-25: LGTM!
51-53: LGTM!src/app/admin/layout.tsx (1)
30-35: LGTM!src/styles/admin.css (1)
74-74: LGTM!src/lib/sentry-options.ts (1)
16-18: LGTM!.release-please-manifest.json (1)
1-3: LGTM!AGENTS.md (1)
196-203: LGTM!
| on: | ||
| push: | ||
| branches: [main] |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- .github/workflows/release-please.yml ---'
cat -n .github/workflows/release-please.ymlRepository: konradciok/ceramics-drop
Length of output: 1192
🌐 Web query:
release-please GitHub Actions concurrency recommended workflow release PR race conditions
💡 Result:
To effectively manage release-please GitHub Actions workflows and prevent race conditions, it is highly recommended to implement workflow-level concurrency [1][2]. ### Recommended Concurrency Configuration Add a concurrency block to your release-please workflow file (e.g.,.github/workflows/release-please.yml). This ensures that only one instance of the release process runs at a time, preventing collisions when multiple commits or PR merges occur in rapid succession [1][3]. yaml concurrency: group: release-please-${{ github.ref }} cancel-in-progress: false * group: Using a dynamic key like release-please-${{ github.ref }} ensures that concurrency is scoped specifically to the branch being released [2]. * cancel-in-progress: false: It is critical to set this to false. If you cancel an in-progress release run, you may leave the release PR or tag in an inconsistent state [2]. ### Why This is Necessary Release-please performs multiple API operations—such as checking for existing PRs, updating PR bodies, pushing commits, and creating GitHub releases—that are not inherently atomic [1][4]. Without serialized execution: * HTTP 409 Conflicts: If two runs simultaneously attempt to update the same release branch or file (like a manifest or LICENSE), the latter will fail with an optimistic locking error because the base reference has changed [1]. * Duplicate/Corrupt PRs: Simultaneous runs may both decide a new PR is needed, leading to race conditions where the second run fails because a PR already exists, or where inconsistent state in the GraphQL API (due to propagation delay) causes the action to create duplicate release PRs [5][6][4]. * Labeling Races: The action often attempts to apply autorelease: pending labels immediately after PR creation; if the PR node ID has not yet propagated, this step may fail [7]. ### Additional Best Practices * Separate Pull Requests: If using separate-pull-requests: true, ensure your concurrency group is robust, as this configuration increases the likelihood of overlapping runs [5][4]. * Handling Label Failures: If your workflow frequently fails due to the label race (where the PR is created but labeling fails), consider setting continue-on-error: true for the release-please action step, or using skip-labeling: true if your process does not rely on those labels [7]. * Version Updates: Always keep googleapis/release-please-action updated to the latest version, as the maintainers regularly release fixes for internal race conditions and API misuse [7][8].
Citations:
- 1: Aureliolo/synthorg@ef7f5c4
- 2: https://github.com/coder/ai-sdk/blob/3077f03c44ed2e63e6666ef422f2c657ea6ef808/.github/workflows/release-please.yml
- 3: https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency
- 4: Validation Failed: A pull request already exists on PR update with separate-pull-requests: true (Go monorepo, v17.6.0) googleapis/release-please#2773
- 5: Collision when merging separate release PRs at the same time googleapis/release-please#2746
- 6: Suggests duplicate release PR in between time release PR merged and release created googleapis/release-please#1208
- 7: Shared _release-please.yml fails on label race after PR creation JacobPEvans-personal/.github#234
- 8: fix: push release PR updates via Git Data API instead of code-suggester googleapis/release-please#2774
Zserializuj uruchomienia release-please.
Dwa szybkie push’e do main mogą uruchomić równoległe runy, które będą aktualizować ten sam release PR i stan wersji. Dodaj concurrency z cancel-in-progress: false, żeby te operacje nie nachodziły na siebie.
Proponowana poprawka
on:
push:
branches: [main]
+
+concurrency:
+ group: release-please-${{ github.ref }}
+ cancel-in-progress: false📝 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.
| on: | |
| push: | |
| branches: [main] | |
| on: | |
| push: | |
| branches: [main] | |
| concurrency: | |
| group: release-please-${{ github.ref }} | |
| cancel-in-progress: false |
🧰 Tools
🪛 zizmor (1.26.1)
[warning] 8-10: insufficient job-level concurrency limits (concurrency-limits): workflow is missing concurrency setting
(concurrency-limits)
🤖 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-please.yml around lines 8 - 10, Dodaj sekcję
concurrency do workflow release-please z grupą identyfikującą jego uruchomienia
oraz ustawieniem cancel-in-progress: false, aby kolejne uruchomienia były
kolejkowane zamiast anulować lub wykonywać się równolegle. Zachowaj istniejący
trigger push dla gałęzi main.
Source: Linters/SAST tools
| permissions: | ||
| contents: write | ||
| pull-requests: write |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- .github/workflows/release-please.yml ---'
cat -n .github/workflows/release-please.yml
printf '\n%s\n' '--- search for release-please usage/docs in repo ---'
rg -n "release-please|issues: write|pull-requests: write|contents: write" .github . -g '!**/node_modules/**' || trueRepository: konradciok/ceramics-drop
Length of output: 2223
🌐 Web query:
release-please-action required permissions contents write issues write pull-requests write documentation
💡 Result:
To configure the release-please-action, you must explicitly set the following permissions in your GitHub Actions workflow file to allow the action to manage releases, pull requests, and issues effectively [1][2][3]: permissions: contents: write issues: write pull-requests: write In addition to these workflow-level permissions, you may need to ensure that your repository settings allow GitHub Actions to create and approve pull requests [2][4]. Go to your repository settings under Actions > General and verify that "Allow GitHub Actions to create and approve pull requests" is enabled [2][5]. If you are using a Personal Access Token (PAT) instead of the default GITHUB_TOKEN—for example, if you require the action to trigger other workflows—you should ensure the PAT has the appropriate scopes [2][4]. Users have reported that in some configurations, additional permissions such as Actions (Read-only) may be required on the PAT to avoid "Resource not accessible" errors [6].
Citations:
- 1: https://github.com/googleapis/release-please-action
- 2: https://github.com/googleapis/release-please-action/blob/main/README.md
- 3: https://github.com/release-please-oss/release-please-action
- 4: https://github.com/marketplace/actions/release-please-action
- 5: https://github.com/google-github-actions/release-please-action?tab=readme-ov-file
- 6: Comments on "Resource not accessible by personal access token" error (fixed by adding Actions: Read-only permission) googleapis/release-please-action#1048
Dodaj issues: write do .github/workflows/release-please.yml. release-please-action oczekuje też dostępu do issues; bez tego obsługa release PR-a i etykiet może się nie udać.
🧰 Tools
🪛 zizmor (1.26.1)
[error] 13-13: overly broad permissions (excessive-permissions): contents: write is overly broad at the workflow level
(excessive-permissions)
[error] 14-14: overly broad permissions (excessive-permissions): pull-requests: write is overly broad at the workflow level
(excessive-permissions)
[warning] 13-13: permissions without explanatory comments (undocumented-permissions): needs an explanatory comment
(undocumented-permissions)
🤖 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-please.yml around lines 12 - 14, Add the missing
issues: write permission to the workflow-level permissions block in
release-please.yml, alongside contents and pull-requests, so
release-please-action can manage release PR issues and labels.
Source: MCP tools
| - uses: googleapis/release-please-action@8b8fd2cc23b2e18957157a9d923d75aa0c6f6ad5 # v4 | ||
| with: | ||
| release-type: node | ||
| # Single root package → tags as v0.7.1, not ceramics-drop-v0.7.1. | ||
| include-component-in-tag: false |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '## files\n'
git ls-files '.github/workflows/release-please.yml' '.release-please-manifest.json' 'release-please*.json' 'release-please*.yml' 'package.json' 'packages/**/package.json' | sed 's#^`#-` #'
printf '\n## workflow\n'
cat -n .github/workflows/release-please.yml
printf '\n## manifest\n'
if [ -f .release-please-manifest.json ]; then
cat -n .release-please-manifest.json
else
echo 'missing .release-please-manifest.json'
fi
printf '\n## release-please config references\n'
rg -n --hidden --glob '!.git' 'release-please|include-component-in-tag|release-type' .Repository: konradciok/ceramics-drop
Length of output: 2364
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the release-please workflow and any nearby config files for the exact mode in use.
sed -n '1,120p' .github/workflows/release-please.yml
printf '\n---\n'
if [ -f .release-please-manifest.json ]; then
sed -n '1,120p' .release-please-manifest.json
fi
printf '\n---\n'
rg -n --hidden --glob '!.git' 'release-type:|include-component-in-tag:|release-please-manifest|release-please-config|release-please' .github . 2>/dev/nullRepository: konradciok/ceramics-drop
Length of output: 2550
🌐 Web query:
release-please-action manifest mode release-type node include-component-in-tag false docs
💡 Result:
In release-please, when using manifest mode with a node release-type, the include-component-in-tag configuration option controls whether the component name is prefixed to your tags and branches [1][2][3]. Setting include-component-in-tag to false is a common configuration for single-package repositories or when you wish to avoid component-specific prefixes in your version tags [4][5]. By default, release-please may include the component name in tags to support monorepos with multiple independent packages [6][5]. When set to false, release-please will generate tags in the format v (e.g., v1.0.0) instead of -v [4]. To apply this configuration in your release-please-config.json, you can add it to the root or to a specific package entry: { "packages": { ".": { "release-type": "node", "include-component-in-tag": false } } } Note that if you are working with a single-package node repository, ensure your configuration correctly points to the root directory (.) as the package path [7][5]. If include-component-in-tag is set to false, release-please will search for tags matching the version number directly, which helps in preventing "tag not found" errors when your repository history does not include component prefixes [4][5]. If you encounter issues where releases are not being triggered, verify that your manifest file (.release-please-manifest.json) is correctly tracking the version for your package [4][5].
Citations:
- 1: https://github.com/googleapis/release-please-action/blob/main/README.md
- 2: https://github.com/marketplace/actions/release-please-action
- 3: https://cdn.jsdelivr.net/npm/release-please@17.2.0/build/src/manifest.d.ts
- 4: https://github.com/googleapis/release-please/blob/refs/heads/main/docs/manifest-releaser.md
- 5: https://github.com/googleapis/release-please/blob/main/docs/troubleshooting.md
- 6: feat: the include-component-in-tag should default to false googleapis/release-please#2216
- 7: https://github.com/googleapis/release-please/blob/HEAD/docs/manifest-releaser.md
🌐 Web query:
googleapis/release-please-action manifest mode release-type docs
💡 Result:
In manifest mode, the release-type should be defined within the release-please configuration file (typically named release-please-config.json) rather than as an input to the GitHub Action [1][2][3]. Setting the release-type input in your GitHub Action workflow can cause the action to ignore your configuration file, as the presence of that input instructs the action to use a default configuration [2][3]. To correctly configure the release-type in manifest mode: 1. Remove the release-type input from your GitHub Action workflow definition [2][3]. 2. Add the release-type to your release-please-config.json file [4][5]. You can set a default release-type at the top level of the configuration file to apply it globally, or you can override it for specific packages by defining it within the individual package configuration [4][5]. Example configuration (release-please-config.json): { "release-type": "node", "packages": { ".": { "release-type": "node" }, "path/to/component": { "release-type": "python" } } } Supported release types include node, python, go, ruby, java, maven, rust, and others [6]. When using manifest mode, ensure your.release-please-manifest.json file exists at the root of your repository (or the path specified) [4][7].
Citations:
- 1: https://github.com/marketplace/actions/release-please-action
- 2: manifest-file input ignored googleapis/release-please-action#1088
- 3: Release-type input overrides config file googleapis/release-please-action#975
- 4: https://github.com/googleapis/release-please/blob/HEAD/docs/manifest-releaser.md
- 5: https://github.com/googleapis/release-please/blob/master/docs/manifest-releaser.md
- 6: https://github.com/googleapis/release-please/blob/HEAD/docs/customizing.md
- 7: https://github.com/googleapis/release-please/blob/HEAD/docs/cli.md
🌐 Web query:
release-please-action README manifest mode release-type config-file manifest-file
💡 Result:
In the googleapis/release-please-action, "manifest mode" is the default behavior used to manage releases for monorepos or projects requiring complex configurations [1][2]. It is activated by default when you do not explicitly set a release-type option (e.g., node, ruby, go) [1][2]. Key configuration details for manifest mode include: 1. config-file: This parameter specifies the path to your release-please configuration file in your repository [1][2]. It defaults to release-please-config.json [1][2]. 2. manifest-file: This parameter specifies the path to your release-please versions manifest file [1][2]. It defaults to.release-please-manifest.json [1][2]. To use manifest mode, ensure that: - A manifest file (e.g.,.release-please-manifest.json) exists at the tip of your target branch [3][4]. It can be empty when initializing, but it must be present [3][5]. - You omit the release-type option in your workflow configuration to allow the action to default to manifest-based handling [1][2]. If you explicitly define a release-type, the action will attempt to use a single-package release strategy rather than the manifest-driven approach [1][2]. If you are encountering issues where the action is not reading your configuration files, ensure that paths are correctly specified and that you are not unintentionally setting a release-type that overrides the default behavior [6].
Citations:
- 1: https://github.com/googleapis/release-please-action/blob/main/README.md
- 2: https://github.com/marketplace/actions/release-please-action
- 3: https://github.com/googleapis/release-please/blob/main/docs/manifest-releaser.md
- 4: https://github.com/googleapis/release-please/blob/refs/heads/main/docs/manifest-releaser.md
- 5: https://github.com/googleapis/release-please/blob/HEAD/docs/manifest-releaser.md
- 6: config-file and manifest-config are not used in GitHub Action googleapis/release-please-action#1057
Przenieś release-type do konfiguracji release-please
release-type: node w .github/workflows/release-please.yml:20-24 omija konfigurację manifestową. Usuń ten input z workflow i ustaw release-type w release-please-config.json.
🤖 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-please.yml around lines 20 - 24, Remove the
release-type input from the release-please action configuration in the workflow,
and add the equivalent release-type setting to release-please-config.json so the
manifest configuration controls the release type.
Source: MCP tools
1 participant
What
Introduces tracked semver releases starting at 0.7.0, bumped automatically from the repo's existing Conventional Commits, and surfaces the running version where it's useful (admin header + Sentry).
package.jsonversionis the single source of truth — badge, Sentryrelease, git tags, and CHANGELOG all derive from it.Changes
package.json0.1.0→0.7.0(canonical version)next.config.tsNEXT_PUBLIC_APP_VERSION(from package.json) + best-effortNEXT_PUBLIC_GIT_SHA(git rev-parse, falls back todev); tag source-map upload with the same releasesrc/app/admin/layout.tsx+src/styles/admin.cssv0.7.0 · <sha>badge in the admin header (reuses the.adm-top-tagpill)src/lib/sentry-options.tsrelease: NEXT_PUBLIC_APP_VERSION— every Sentry event correlates to the version that shipped it.github/workflows/release-please.ymlvX.Y.Ztag.release-please-manifest.jsonAGENTS.mdCommit → version mapping (documented in AGENTS.md § Versioning)
feat:→ minor (0.8.0) ·fix:/perf:→ patch (0.7.x) ·feat!:/BREAKING CHANGE:→ major (1.0.0).chore:/docs:/test:/refactor:/ci:do not cut a standalone release — they fold into the nextfeat:/fix:. So title routine shipping PRsfix:/feat:, notchore:.After merge, create the baseline so release-please doesn't recompute from all 150+ historical commits:
3ec4c21(the gate-#2.env.exampleedit)That commit added
FULFULMENT_DEBUG_TOKEN=— a typo; the code readsenv.FULFILMENT_DEBUG_TOKEN(one F, one L: F-U-L-F-I-L-M-E-N-T). Please fix.env.exampletoFULFILMENT_DEBUG_TOKEN=before merge — anyone copying the example as-is would set a var the debug route won't recognize (fail-closed 404, breaks the C-12 destructive E2E auth). I couldn't edit it (.env.exampleis permission-denied in my environment).Verification
npm run typecheck— clean (app + worker).npm run test— 1207/1207 passing (110 files).npm run build— green, staysnext build --webpack;NEXT_PUBLIC_APP_VERSIONconfirmed inlined into the admin server bundles.pr-review/.diffs/*scratch).🤖 Generated with Claude Code