feat: add generic release-please flow - #5
Conversation
Signed-off-by: Prasanth Baskar <prasanth@8gears.com>
github-actions
Bot
added
documentation
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.OpenSSF Scorecard
Scanned Files
|
📝 WalkthroughWalkthroughChangesRepository automation
Sequence Diagram(s)sequenceDiagram
participant ReleasePleaseWorkflow
participant ReleaseAssetsWorkflow
participant Taskfile
ReleasePleaseWorkflow->>ReleaseAssetsWorkflow: invoke with release tag
ReleaseAssetsWorkflow->>Taskfile: run release-assets
Taskfile->>ReleaseAssetsWorkflow: return platform binaries
ReleaseAssetsWorkflow->>ReleasePleaseWorkflow: upload assets to release tag
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
✨ Simplify code
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 |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Thanks for your first pull request! 🎉
A maintainer will review this soon. Please ensure:
- Tests pass locally
- Code follows our style guidelines
- Commits are signed off (DCO)
- PR title follows Conventional Commits
Check out our Contributing Guide for more details.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 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/scripts/apply-settings.js:
- Line 101: Update the apply-mode call to applyActions so a rejected update
propagates and fails the job instead of being converted into a warning; remove
the catch-based swallowing while preserving the existing error context if
needed.
- Around line 115-121: The Actions workflow permissions request in
exportSettings must preserve an explicit unavailable state when it fails, rather
than omitting actions and allowing detectDrift to report false drift. Update the
handling around the GET /repos/{owner}/{repo}/actions/permissions/workflow
request and the related check/verify path near the other referenced logic to
either skip comparison for unavailable permissions or fail clearly with “cannot
verify Actions permissions,” while retaining normal comparisons when the policy
is readable.
In `@CHECKLIST.md`:
- Around line 125-126: Document least-privilege permissions for custom
post-release jobs: in CHECKLIST.md lines 125-126, add a checklist item requiring
job-level permissions for the target artifact or registry; in docs/RELEASES.md
lines 28-41, add a job-level permissions example and clearly distinguish
release-please permissions from publication-job permissions.
In `@README.md`:
- Line 187: Revise the release-type guidance in README.md at lines 187-187 and
docs/RELEASES.md at lines 26-26: remove go from the native version-file list,
keep simple/version.txt for generic native version updates, and describe go
separately as the Go release strategy while preserving the packages monorepo
guidance.
🪄 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: CHILL
Plan: Pro Plus
Run ID: cd7437cf-7ca7-435c-ba1d-18a0af4ddedc
📒 Files selected for processing (12)
.github/scripts/apply-settings.js.github/settings.yml.github/workflows/apply-settings.yml.github/workflows/release-assets.yml.github/workflows/release-please.yml.release-please-manifest.jsonCHECKLIST.mdREADME.mdTaskfile.ymldocs/RELEASES.mdrelease-please-config.jsonversion.txt
| // Apply all settings with error handling | ||
| async function applyAll() { | ||
| await applyRepository().catch(e => core.warning(`repository: ${e.message} (needs SETTINGS_TOKEN?)`)) | ||
| await applyActions().catch(e => core.warning(`actions: ${e.message} (needs SETTINGS_TOKEN?)`)) |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '## repo files of interest\n'
git ls-files | rg '(^\.github/scripts/apply-settings\.js$|^\.github/workflows/apply-settings\.yml$)' || true
printf '\n## apply-settings.js outline\n'
ast-grep outline .github/scripts/apply-settings.js || true
printf '\n## relevant apply-settings.js lines\n'
sed -n '1,180p' .github/scripts/apply-settings.js
printf '\n## relevant apply-settings workflow lines\n'
sed -n '1,120p' .github/workflows/apply-settings.ymlRepository: container-registry/oss-project-template
Length of output: 8785
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '## apply-settings.js remaining core sections\n'
sed -n '180,340p' .github/scripts/apply-settings.jsRepository: container-registry/oss-project-template
Length of output: 5445
Do not swallow the Actions permissions API error.
In apply mode, applyActions() failing still only logs a warning, so the workflow can succeed without applying settings.actions. In verify mode, detectDrift() can detect the failure, but the default workflow_dispatch mode is apply. Fail the job when this update rejects.
🤖 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/scripts/apply-settings.js at line 101, Update the apply-mode call to
applyActions so a rejected update propagates and fails the job instead of being
converted into a warning; remove the catch-based swallowing while preserving the
existing error context if needed.
| let actionsData | ||
| try { | ||
| const actions = await github.request('GET /repos/{owner}/{repo}/actions/permissions/workflow', { owner, repo }) | ||
| actionsData = actions.data | ||
| } catch (e) { | ||
| // Actions workflow permissions are unavailable without repository admin access | ||
| } |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Files:"
git ls-files | rg '(^|/)apply-settings\.js$|package\.json|README|\.github/scripts' || true
echo
echo "apply-settings outline:"
if [ -f .github/scripts/apply-settings.js ]; then
wc -l .github/scripts/apply-settings.js
ast-grep outline .github/scripts/apply-settings.js || true
echo
echo "Relevant sections:"
nl -ba .github/scripts/apply-settings.js | sed -n '1,240p'
fiRepository: container-registry/oss-project-template
Length of output: 437
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Relevant apply-settings.js sections:"
python3 - <<'PY'
from pathlib import Path
p = Path('.github/scripts/apply-settings.js')
lines = p.read_text().splitlines()
for start,end,label in [(1,260,'Top to detectDrift area'), (1,220,'Top 220 lines')]:
print('---', label, '---')
for i in range(start, min(end, len(lines))+1):
print(f'{i:4}: {lines[i-1]}')
PY
echo
echo "Search for detectDrift/exportSettings/actions usage:"
python3 - <<'PY'
from pathlib import Path
p = '.github/scripts/apply-settings.js'
for term in ['actionsData', 'exportSettings', 'detectDrift', 'actions', 'workflowPermissions']:
print(f'--- {term} ---')
for n,line in enumerate(Path(p).read_text().splitlines(), 1):
if term in line:
print(f'{n}: {line}')
PYRepository: container-registry/oss-project-template
Length of output: 23874
🏁 Script executed:
#!/bin/bash
set -euo pipefail
python3 - <<'PY'
from pathlib import Path
lines = Path('.github/scripts/apply-settings.js').read_text().splitlines()
for i, line in enumerate(lines, 1):
if 'async function detectDrift' in line or i in range(242, 316):
print(f'{i:4}: {line}')
print('--- JS semantic probe ---')
const_export = {
"actions": {
"default_workflow_permissions": "read",
"can_approve_pull_request_reviews": True
}
}
actions_data = None
result_actions = {
"default_workflow_permissions": actions_data["default_workflow_permissions"],
"can_approve_pull_request_reviews": actions_data["can_approve_pull_request_reviews"]
} if actions_data else None
import json
print(json.dumps({
"configured": const_export["actions"],
"exported": result_actions,
"detects_drift_if_actions_is_defined_and_export_omits_it": "actions" in const_export and ("actions" not in result_actions or result_actions.get("actions") is None)
}, indent=2))
PYRepository: container-registry/oss-project-template
Length of output: 3041
Do not treat an unreadable Actions policy as drift.
When GET /repos/{owner}/{repo}/actions/permissions/workflow fails, exportSettings() omits actions, and detectDrift() compares that against the configured settings.actions. check and verify then fail. Preserve an explicit unavailable state or fail with a clear “cannot verify Actions permissions” error because read-only access to Actions permissions is required.
Also applies to: .github/scripts/apply-settings.js:181-184.
🤖 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/scripts/apply-settings.js around lines 115 - 121, The Actions
workflow permissions request in exportSettings must preserve an explicit
unavailable state when it fails, rather than omitting actions and allowing
detectDrift to report false drift. Update the handling around the GET
/repos/{owner}/{repo}/actions/permissions/workflow request and the related
check/verify path near the other referenced logic to either skip comparison for
unavailable permissions or fail clearly with “cannot verify Actions
permissions,” while retaining normal comparisons when the policy is readable.
| - [ ] No changes needed for changelog/tag automation (uses `release-please-config.json`) | ||
| - [ ] Add post-release jobs here if publishing images, charts, binaries, or other artifacts |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Document least-privilege permissions for custom release jobs.
The workflow denies permissions by default and grants contents: write per job. The post-release extension guidance must require custom jobs to declare the permissions needed for their publication target.
CHECKLIST.md#L125-L126: add a checklist item for job-level artifact or registry permissions.docs/RELEASES.md#L28-L41: include a job-levelpermissionsexample and distinguish release-please permissions from publication-job permissions.
📍 Affects 2 files
CHECKLIST.md#L125-L126(this comment)docs/RELEASES.md#L28-L41
🤖 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 `@CHECKLIST.md` around lines 125 - 126, Document least-privilege permissions
for custom post-release jobs: in CHECKLIST.md lines 125-126, add a checklist
item requiring job-level permissions for the target artifact or registry; in
docs/RELEASES.md lines 28-41, add a job-level permissions example and clearly
distinguish release-please permissions from publication-job permissions.
| - Independent version tracking in `.release-please-manifest.json` | ||
| - Separate GitHub releases (e.g., `app-v1.0.0`, `helm-chart-v0.5.0`) | ||
| - Its own CHANGELOG.md in its directory | ||
| Use `go`, `node`, `python`, `rust`, or `helm` when release-please should update the project's native version file. Monorepos can add package paths under `packages`; each path gets independent version tracking and a changelog. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== locate files =="
git ls-files | rg '(^|/)(README\.md|docs/RELEASES\.md|CHECKLIST\.md)$' || true
echo
echo "== release-please references =="
rg -n "release-please|release-type|version\.txt|go|namespace|package" README.md docs/RELEASES.md CHECKLIST.md .github 2>/dev/null || true
echo
echo "== changed/stat =="
git diff --stat || true
git diff -- README.md docs/RELEASES.md CHECKLIST.md 2>/dev/null | sed -n '1,220p' || trueRepository: container-registry/oss-project-template
Length of output: 7203
🌐 Web query:
release-please Go release type version.txt simple language specific release types
💡 Result:
In release-please, the simple release type is specifically designed for repositories that track their version in a version.txt file [1][2]. When using the simple release strategy, release-please maintains this file automatically, updating the version number within it whenever a new release is generated [3][4]. It is important to note that a version.txt file is treated as an output, not an input [3]. You do not need to manually edit this file to signal a version bump; release-please determines the next version based on the latest detected release and conventional commit messages [3]. If you are using the simple strategy, release-please will create the version.txt file if it does not already exist [4]. Regarding the Go release type: 1. The go release type is intended for projects that typically only require a CHANGELOG.md update [1][2]. 2. While some users have attempted to point a Go project to a version file (like a version.go file) using the version-file configuration option, this has historically been inconsistent or ignored depending on the project configuration [5]. 3. Unlike the simple release type, the go release type does not natively use a version.txt file as its primary version tracking mechanism [1][2]. If you are using the simple strategy and observe that your version.txt is being ignored or not updated as expected, ensure that you are not attempting to manually manage the version number via that file, as the tool is designed to control it automatically [3]. If you need to force a specific version, you can use the Release-As footer in a commit message (e.g., Release-As: 1.0.0) to override the automated versioning [3].
Citations:
- 1: https://github.com/googleapis/release-please/blob/a61fa929b42f04c6acdd6650328d3f90903b7dc5/docs/customizing.md
- 2: https://github.com/googleapis/release-please/blob/main/docs/customizing.md
- 3: Simple strategy ignores version.txt googleapis/release-please#2098
- 4: fix(simple): create version.txt if it does not exist googleapis/release-please#534
- 5: For release-type go projects version-file is ignored. googleapis/release-please#2541
Keep Go’s version.txt guidance out of the native release-type list.
go does not follow a generic native version-file pattern here; keep simple/version.txt for that behavior and describe go separately as the Go release strategy.
README.md#L187-L187: revise the language-specific release-type description.docs/RELEASES.md#L26-L26: revise the equivalent release-type guidance.
📍 Affects 2 files
README.md#L187-L187(this comment)docs/RELEASES.md#L26-L26
🤖 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 `@README.md` at line 187, Revise the release-type guidance in README.md at
lines 187-187 and docs/RELEASES.md at lines 26-26: remove go from the native
version-file list, keep simple/version.txt for generic native version updates,
and describe go separately as the Go release strategy while preserving the
packages monorepo guidance.
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
8 issues found across 12 files
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="version.txt">
<violation number="1" location="version.txt:1">
P2: New adopters inherit `1.1.0` as the release baseline, so the first conventional `feat`/`fix` release is calculated as `1.2.0`/`1.1.1` instead of the documented `0.0.0` baseline. Please seed the template version consistently at `0.0.0`, or update the adoption documentation if starting every repository at `1.1.0` is intentional.</violation>
</file>
<file name="CHECKLIST.md">
<violation number="1" location="CHECKLIST.md:126">
P3: The checklist item for adding post-release jobs doesn't mention that, since the workflow now denies permissions by default (`permissions: {}`) and grants `contents: write` only per job, any new post-release job publishing to a registry or artifact store will need to declare its own least-privilege `permissions` block. Consider adding a checklist item for this.</violation>
<violation number="2" location="CHECKLIST.md:179">
P2: These commit types are documented as non-releasing, but the current release-please configuration exposes them as release-note sections and release-please treats such visible commits as patch releases. Please either hide these sections/configure explicit release rules or document them as patch-triggering types so adopters do not mispredict when releases are created.</violation>
</file>
<file name=".github/workflows/release-please.yml">
<violation number="1" location=".github/workflows/release-please.yml:18">
P1: Release-please can fail while creating or maintaining the release PR because v5 labels it through the Issues API, but this job omits the required `issues: write` permission; include that permission with the existing release-please scopes.</violation>
</file>
<file name="docs/RELEASES.md">
<violation number="1" location="docs/RELEASES.md:20">
P2: A `fix!:` squash commit is also a breaking release, but this table omits it and can lead maintainers to misclassify the resulting major bump; include `fix!:` in the documented syntax.</violation>
</file>
<file name=".github/scripts/apply-settings.js">
<violation number="1" location=".github/scripts/apply-settings.js:101">
P2: applyActions() failures are only logged as a warning in applyAll(), so the workflow can report success even when the Actions default_workflow_permissions/can_approve_pull_request_reviews settings required for release-please PRs were not actually applied. Consider failing the job (or surfacing a clear error) when this update rejects, since the default workflow_dispatch mode is `apply`.</violation>
<violation number="2" location=".github/scripts/apply-settings.js:119">
P2: Repository-settings verification can fail with false drift when the token lacks admin access. The new export path silently omits `actions` after a GET failure, but `settings.yml` always contains that block, so the normalized expected and actual objects can never match. Preserving an explicit “unavailable” state and skipping this field from comparison (or failing with an access-specific diagnostic) would avoid treating inability to read the setting as a configuration mismatch.</violation>
</file>
<file name="README.md">
<violation number="1" location="README.md:187">
P3: Grouping `go` together with `node`, `python`, `rust`, and `helm` as release types that update 'the project's native version file' is misleading: release-please's `go` release-type doesn't maintain a native version file (it's documented as just a repository with a CHANGELOG.md), unlike the other listed types which do update package.json/pyproject.toml/Cargo.toml/Chart.yaml. Consider describing `go` separately from the native-version-file group.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
| timeout-minutes: 10 | ||
| permissions: | ||
| contents: write | ||
| pull-requests: write |
There was a problem hiding this comment.
P1: Release-please can fail while creating or maintaining the release PR because v5 labels it through the Issues API, but this job omits the required issues: write permission; include that permission with the existing release-please scopes.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/release-please.yml, line 18:
<comment>Release-please can fail while creating or maintaining the release PR because v5 labels it through the Issues API, but this job omits the required `issues: write` permission; include that permission with the existing release-please scopes.</comment>
<file context>
@@ -1,24 +1,38 @@
+ timeout-minutes: 10
+ permissions:
+ contents: write
+ pull-requests: write
outputs:
release_created: ${{ steps.release.outputs.release_created }}
</file context>
| pull-requests: write | |
| issues: write | |
| pull-requests: write |
| @@ -0,0 +1 @@ | |||
| 1.1.0 | |||
There was a problem hiding this comment.
P2: New adopters inherit 1.1.0 as the release baseline, so the first conventional feat/fix release is calculated as 1.2.0/1.1.1 instead of the documented 0.0.0 baseline. Please seed the template version consistently at 0.0.0, or update the adoption documentation if starting every repository at 1.1.0 is intentional.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At version.txt, line 1:
<comment>New adopters inherit `1.1.0` as the release baseline, so the first conventional `feat`/`fix` release is calculated as `1.2.0`/`1.1.1` instead of the documented `0.0.0` baseline. Please seed the template version consistently at `0.0.0`, or update the adoption documentation if starting every repository at `1.1.0` is intentional.</comment>
<file context>
@@ -0,0 +1 @@
+1.1.0
</file context>
| | `build:` | Patch | `build: update Dockerfile` | | ||
| | `ci:` | Patch | `ci: fix workflow permissions` | | ||
| | `feat!:` or `fix!:` | Major (minor on 0.x) | `feat!: redesign API endpoints` | | ||
| | `docs:`, `perf:`, `refactor:`, `revert:` | None (included in next release) | `docs: update README` | |
There was a problem hiding this comment.
P2: These commit types are documented as non-releasing, but the current release-please configuration exposes them as release-note sections and release-please treats such visible commits as patch releases. Please either hide these sections/configure explicit release rules or document them as patch-triggering types so adopters do not mispredict when releases are created.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At CHECKLIST.md, line 179:
<comment>These commit types are documented as non-releasing, but the current release-please configuration exposes them as release-note sections and release-please treats such visible commits as patch releases. Please either hide these sections/configure explicit release rules or document them as patch-triggering types so adopters do not mispredict when releases are created.</comment>
<file context>
@@ -171,14 +175,9 @@ This template uses conventional commits for automatic versioning:
-| `build:` | Patch | `build: update Dockerfile` |
-| `ci:` | Patch | `ci: fix workflow permissions` |
+| `feat!:` or `fix!:` | Major (minor on 0.x) | `feat!: redesign API endpoints` |
+| `docs:`, `perf:`, `refactor:`, `revert:` | None (included in next release) | `docs: update README` |
+| `ci:`, `chore:`, `build:`, `style:`, `test:` | None (hidden) | `chore: update dependencies` |
</file context>
| |-------------|----------------|---------------| | ||
| | `feat:` | Minor | Features | | ||
| | `fix:` | Patch | Bug Fixes | | ||
| | `feat!:` or `BREAKING CHANGE:` | Major (minor while on 0.x) | Breaking changes | |
There was a problem hiding this comment.
P2: A fix!: squash commit is also a breaking release, but this table omits it and can lead maintainers to misclassify the resulting major bump; include fix!: in the documented syntax.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At docs/RELEASES.md, line 20:
<comment>A `fix!:` squash commit is also a breaking release, but this table omits it and can lead maintainers to misclassify the resulting major bump; include `fix!:` in the documented syntax.</comment>
<file context>
@@ -0,0 +1,43 @@
+|-------------|----------------|---------------|
+| `feat:` | Minor | Features |
+| `fix:` | Patch | Bug Fixes |
+| `feat!:` or `BREAKING CHANGE:` | Major (minor while on 0.x) | Breaking changes |
+| `perf:`, `revert:`, `docs:`, `refactor:` | None | Included in the next release |
+| `ci:`, `chore:`, `build:`, `style:`, `test:` | None | Hidden |
</file context>
| | `feat!:` or `BREAKING CHANGE:` | Major (minor while on 0.x) | Breaking changes | | |
| | `feat!:`, `fix!:`, or `BREAKING CHANGE:` | Major (minor while on 0.x) | Breaking changes | |
| try { | ||
| const actions = await github.request('GET /repos/{owner}/{repo}/actions/permissions/workflow', { owner, repo }) | ||
| actionsData = actions.data | ||
| } catch (e) { |
There was a problem hiding this comment.
P2: Repository-settings verification can fail with false drift when the token lacks admin access. The new export path silently omits actions after a GET failure, but settings.yml always contains that block, so the normalized expected and actual objects can never match. Preserving an explicit “unavailable” state and skipping this field from comparison (or failing with an access-specific diagnostic) would avoid treating inability to read the setting as a configuration mismatch.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At .github/scripts/apply-settings.js, line 119:
<comment>Repository-settings verification can fail with false drift when the token lacks admin access. The new export path silently omits `actions` after a GET failure, but `settings.yml` always contains that block, so the normalized expected and actual objects can never match. Preserving an explicit “unavailable” state and skipping this field from comparison (or failing with an access-specific diagnostic) would avoid treating inability to read the setting as a configuration mismatch.</comment>
<file context>
@@ -102,6 +112,14 @@ module.exports = async ({ github, context, core }) => {
+ try {
+ const actions = await github.request('GET /repos/{owner}/{repo}/actions/permissions/workflow', { owner, repo })
+ actionsData = actions.data
+ } catch (e) {
+ // Actions workflow permissions are unavailable without repository admin access
+ }
</file context>
| // Apply all settings with error handling | ||
| async function applyAll() { | ||
| await applyRepository().catch(e => core.warning(`repository: ${e.message} (needs SETTINGS_TOKEN?)`)) | ||
| await applyActions().catch(e => core.warning(`actions: ${e.message} (needs SETTINGS_TOKEN?)`)) |
There was a problem hiding this comment.
P2: applyActions() failures are only logged as a warning in applyAll(), so the workflow can report success even when the Actions default_workflow_permissions/can_approve_pull_request_reviews settings required for release-please PRs were not actually applied. Consider failing the job (or surfacing a clear error) when this update rejects, since the default workflow_dispatch mode is apply.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At .github/scripts/apply-settings.js, line 101:
<comment>applyActions() failures are only logged as a warning in applyAll(), so the workflow can report success even when the Actions default_workflow_permissions/can_approve_pull_request_reviews settings required for release-please PRs were not actually applied. Consider failing the job (or surfacing a clear error) when this update rejects, since the default workflow_dispatch mode is `apply`.</comment>
<file context>
@@ -89,6 +98,7 @@ module.exports = async ({ github, context, core }) => {
// Apply all settings with error handling
async function applyAll() {
await applyRepository().catch(e => core.warning(`repository: ${e.message} (needs SETTINGS_TOKEN?)`))
+ await applyActions().catch(e => core.warning(`actions: ${e.message} (needs SETTINGS_TOKEN?)`))
await applyLabels().catch(e => core.warning(`labels: ${e.message}`))
await applySecurity().catch(e => core.warning(`security: ${e.message} (needs SETTINGS_TOKEN?)`))
</file context>
|
|
||
| - [ ] No changes needed (uses `release-please-config.json`) | ||
| - [ ] No changes needed for changelog/tag automation (uses `release-please-config.json`) | ||
| - [ ] Add post-release jobs here if publishing images, charts, binaries, or other artifacts |
There was a problem hiding this comment.
P3: The checklist item for adding post-release jobs doesn't mention that, since the workflow now denies permissions by default (permissions: {}) and grants contents: write only per job, any new post-release job publishing to a registry or artifact store will need to declare its own least-privilege permissions block. Consider adding a checklist item for this.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At CHECKLIST.md, line 126:
<comment>The checklist item for adding post-release jobs doesn't mention that, since the workflow now denies permissions by default (`permissions: {}`) and grants `contents: write` only per job, any new post-release job publishing to a registry or artifact store will need to declare its own least-privilege `permissions` block. Consider adding a checklist item for this.</comment>
<file context>
@@ -121,7 +122,8 @@ diff .github/settings.yml current.yml
-- [ ] No changes needed (uses `release-please-config.json`)
+- [ ] No changes needed for changelog/tag automation (uses `release-please-config.json`)
+- [ ] Add post-release jobs here if publishing images, charts, binaries, or other artifacts
### `.github/workflows/release-assets.yml`
</file context>
| - [ ] Add post-release jobs here if publishing images, charts, binaries, or other artifacts | |
| - [ ] Add post-release jobs here if publishing images, charts, binaries, or other artifacts (declare the least-privilege `permissions` needed for the publication target, e.g. `packages: write`) |
| - Independent version tracking in `.release-please-manifest.json` | ||
| - Separate GitHub releases (e.g., `app-v1.0.0`, `helm-chart-v0.5.0`) | ||
| - Its own CHANGELOG.md in its directory | ||
| Use `go`, `node`, `python`, `rust`, or `helm` when release-please should update the project's native version file. Monorepos can add package paths under `packages`; each path gets independent version tracking and a changelog. |
There was a problem hiding this comment.
P3: Grouping go together with node, python, rust, and helm as release types that update 'the project's native version file' is misleading: release-please's go release-type doesn't maintain a native version file (it's documented as just a repository with a CHANGELOG.md), unlike the other listed types which do update package.json/pyproject.toml/Cargo.toml/Chart.yaml. Consider describing go separately from the native-version-file group.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At README.md, line 187:
<comment>Grouping `go` together with `node`, `python`, `rust`, and `helm` as release types that update 'the project's native version file' is misleading: release-please's `go` release-type doesn't maintain a native version file (it's documented as just a repository with a CHANGELOG.md), unlike the other listed types which do update package.json/pyproject.toml/Cargo.toml/Chart.yaml. Consider describing `go` separately from the native-version-file group.</comment>
<file context>
@@ -168,25 +171,22 @@ Edit `.typos.toml` to add project-specific terms:
-- Independent version tracking in `.release-please-manifest.json`
-- Separate GitHub releases (e.g., `app-v1.0.0`, `helm-chart-v0.5.0`)
-- Its own CHANGELOG.md in its directory
+Use `go`, `node`, `python`, `rust`, or `helm` when release-please should update the project's native version file. Monorepos can add package paths under `packages`; each path gets independent version tracking and a changelog.
-Commits are attributed to packages based on changed paths. Remove the `charts/app` entry if not using Helm.
</file context>
| Use `go`, `node`, `python`, `rust`, or `helm` when release-please should update the project's native version file. Monorepos can add package paths under `packages`; each path gets independent version tracking and a changelog. | |
| Use `node`, `python`, `rust`, or `helm` when release-please should update the project's native version file (package.json, pyproject.toml, Cargo.toml, or Chart.yaml). Go modules have no native version file, so `go` mode instead tracks the version via CHANGELOG.md only. Monorepos can add package paths under `packages`; each path gets independent version tracking and a changelog. |
1 participant
Summary
version.txttask release-assetsWhy
The existing template referenced a nonexistent Helm package and used component-prefixed release configuration that was not generic. Its separate
release: publishedasset workflow would also not run for releases created withGITHUB_TOKEN.This aligns the template with the proven harbor-scanner-trivy release-please pattern while keeping project-specific publishing replaceable.
Impact
New repositories get conventional-commit releases with
vX.Y.Ztags, generated changelogs, a generic version file, and a working post-release extension point. Existing adopters can switchrelease-typeor replace the example asset task for their language.Validation
go test ./...task release-assetsbuilt Linux, macOS, and Windows binariesSummary by cubic
Adds a generic
release-pleaseflow using thesimplerelease type withversion.txt, upgrades torelease-pleasev5 with least-privilege, and introduces a reusable post-release assets workflow powered bytask release-assets.New Features
version.txtwithvX.Y.Ztags and generated changelogs.googleapis/release-please-action@v5with job-scoped permissions, timeouts, andtag_name/versionoutputs.release-assetsworkflow (workflow_call) uploads artifacts to an existing tag; example Go binaries built viaTaskfile.yml(task release-assets)..github/scripts/apply-settings.jsnow applies and exports them. Docs added indocs/RELEASES.md; README/CHECKLIST updated.Migration
simpletype, or switchrelease-type(e.g.,go,node,python,rust,helm) when ready..release-please-manifest.jsonandversion.txtstart at the same version; remove old component/Helm entries..github/settings.yml(requiresSETTINGS_TOKEN) soactions.can_approve_pull_request_reviews: trueis enforced..github/workflows/release-assets.ymlafter release or replace with your own Task-based job.Written for commit 14d0173. Summary will update on new commits.