release-please

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Setting Up Release-Please

配置Release-Please

This skill guides you through setting up release-please in a repository.

本技能将引导你在代码仓库中配置release-please。

Before You Start

准备工作

Ask the user (if not clear from context):

What language/framework? (determines
```
release-type
```
)
Single package or monorepo?
Current version of the package(s)?

若上下文未明确，需询问用户：

使用的语言/框架是什么？（用于确定
```
release-type
```
）
是单包项目还是单体仓库？
当前包的版本是多少？

Setup Steps

配置步骤

1. Create GitHub Actions Workflow

1. 创建GitHub Actions工作流

Create

.github/workflows/release-please.yml

yaml

on:
  push:
    branches: [main]

permissions:
  contents: write
  pull-requests: write

name: release-please

jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - uses: googleapis/release-please-action@v4
        with:
          release-type: <type>  # See references/release-types.md

创建

.github/workflows/release-please.yml

文件：

yaml

on:
  push:
    branches: [main]

permissions:
  contents: write
  pull-requests: write

name: release-please

jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - uses: googleapis/release-please-action@v4
        with:
          release-type: <type>  # See references/release-types.md

Unified release-please + GoReleaser workflow (recommended when both are used)

统一的release-please + GoReleaser工作流（同时使用两者时推荐）

If the project uses both release-please and GoReleaser, prefer a single workflow file. Run release-please first, then run GoReleaser only when

release_created

true

This avoids the common PAT workaround. You do not need a custom

RELEASE_PLEASE_TOKEN

just to trigger a second workflow for GoReleaser.

For the canonical recipe, see

references/release-please-goreleaser-unified-workflow.md

yaml

name: release-please

on:
  push:
    branches: [main]

permissions:
  contents: write
  pull-requests: write
  packages: write

jobs:
  release-please:
    runs-on: ubuntu-latest
    outputs:
      release_created: ${{ steps.release.outputs.release_created }}
      tag_name: ${{ steps.release.outputs.tag_name }}
    steps:
      - id: release
        uses: googleapis/release-please-action@v4
        with:
          release-type: <type>

  goreleaser:
    needs: release-please
    if: ${{ needs.release-please.outputs.release_created == 'true' }}
    runs-on: ubuntu-latest
    permissions:
      contents: write
      packages: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
          ref: ${{ needs.release-please.outputs.tag_name }}
      - uses: actions/setup-go@v5
        with:
          go-version-file: go.mod
      - uses: goreleaser/goreleaser-action@v6
        with:
          version: latest
          args: release --clean
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

If the user needs CI to run on release PRs (common), they need a PAT for that PR-triggering behavior:

yaml

        with:
          token: ${{ secrets.RELEASE_PLEASE_TOKEN }}

Do not use this PAT requirement as the default fix for release-please + GoReleaser integration. Prefer the unified single-workflow pattern above.

如果项目同时使用release-please和GoReleaser，建议使用单个工作流文件。先运行release-please，仅当

release_created

为

true

时再运行GoReleaser。

这种方式可以避免常见的PAT workaround。你无需自定义

RELEASE_PLEASE_TOKEN

来触发第二个GoReleaser工作流。

关于标准配置方案，请查看

references/release-please-goreleaser-unified-workflow.md

。

yaml

name: release-please

on:
  push:
    branches: [main]

permissions:
  contents: write
  pull-requests: write
  packages: write

jobs:
  release-please:
    runs-on: ubuntu-latest
    outputs:
      release_created: ${{ steps.release.outputs.release_created }}
      tag_name: ${{ steps.release.outputs.tag_name }}
    steps:
      - id: release
        uses: googleapis/release-please-action@v4
        with:
          release-type: <type>

  goreleaser:
    needs: release-please
    if: ${{ needs.release-please.outputs.release_created == 'true' }}
    runs-on: ubuntu-latest
    permissions:
      contents: write
      packages: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
          ref: ${{ needs.release-please.outputs.tag_name }}
      - uses: actions/setup-go@v5
        with:
          go-version-file: go.mod
      - uses: goreleaser/goreleaser-action@v6
        with:
          version: latest
          args: release --clean
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

如果用户需要在发布PR上运行CI（常见需求），则需要PAT来实现该PR触发行为：

yaml

        with:
          token: ${{ secrets.RELEASE_PLEASE_TOKEN }}

不要将此PAT要求作为release-please + GoReleaser集成的默认解决方案，优先采用上述统一单工作流模式。

2. Create Config Files (for advanced setups)

2. 创建配置文件（适用于高级配置）

For monorepos or custom config, create manifest files instead of using

release-type

input.

release-please-config.json:

json

{
  "packages": {
    ".": {
      "release-type": "<type>"
    }
  }
}

.release-please-manifest.json:

json

{
  ".": "<current-version>"
}

Then update the workflow to omit

release-type

yaml

- uses: googleapis/release-please-action@v4
  with:
    token: ${{ secrets.RELEASE_PLEASE_TOKEN }}

对于单体仓库或自定义配置，创建清单文件而非使用

release-type

输入参数。

release-please-config.json：

json

{
  "packages": {
    ".": {
      "release-type": "<type>"
    }
  }
}

.release-please-manifest.json：

json

{
  ".": "<current-version>"
}

随后更新工作流，移除

release-type

参数：

yaml

- uses: googleapis/release-please-action@v4
  with:
    token: ${{ secrets.RELEASE_PLEASE_TOKEN }}

3. Bootstrap Existing Repository

3. 为现有仓库启动配置

For repos with existing releases, set the current version in

.release-please-manifest.json

to match the latest release tag.

If there's extensive commit history, add

bootstrap-sha

to config to limit changelog scope:

json

{
  "bootstrap-sha": "<commit-sha-before-first-desired-commit>",
  "packages": { ... }
}

对于已有发布记录的仓库，需在

.release-please-manifest.json

中设置当前版本以匹配最新发布标签。

如果存在大量提交历史，可在配置中添加

bootstrap-sha

来限制变更日志的范围：

json

{
  "bootstrap-sha": "<commit-sha-before-first-desired-commit>",
  "packages": { ... }
}

Common Setup Patterns

常见配置模式

Node.js Package

Node.js包

```
release-type: node
```
Updates
```
package.json
```
and
```
CHANGELOG.md
```

```
release-type: node
```
更新
```
package.json
```
和
```
CHANGELOG.md
```

Python Package

Python包

```
release-type: python
```
Updates
```
pyproject.toml
```
/
```
setup.py
```
and
```
CHANGELOG.md
```

```
release-type: python
```
更新
```
pyproject.toml
```
/
```
setup.py
```
和
```
CHANGELOG.md
```

Go Module

Go模块

```
release-type: go
```
Updates
```
CHANGELOG.md
```
only (version from tags)

```
release-type: go
```
仅更新
```
CHANGELOG.md
```
（版本来自标签）

Monorepo

单体仓库

Use manifest config with multiple packages
Consider
```
node-workspace
```
or
```
cargo-workspace
```
plugins
See
```
references/manifest-config.md
```

使用包含多个包的清单配置
可考虑
```
node-workspace
```
或
```
cargo-workspace
```
插件
查看
```
references/manifest-config.md
```

Post-Setup Checklist

配置后检查清单

Tell the user:

Commit and push the new files
Start using conventional commits:
```
feat:
```
,
```
fix:
```
,
```
feat!:
```
Use squash-merge for PRs (cleaner changelogs)
Release-please will create a Release PR after releasable commits
Merge the Release PR to create the GitHub release

告知用户：

提交并推送新创建的文件
开始使用规范化提交格式：
```
feat:
```
、
```
fix:
```
、
```
feat!:
```
对PR使用 squash-merge（以生成更清晰的变更日志）
在有可发布的提交后，release-please会创建一个发布PR
合并发布PR即可创建GitHub发布版本

Reference Files

参考文件

Read these for detailed options:

```
references/release-types.md
```
- All supported languages
```
references/github-actions.md
```
- Action inputs, outputs, examples
```
references/manifest-config.md
```
- Full config options, plugins, monorepos
```
references/release-please-goreleaser-unified-workflow.md
```
- Canonical combined setup for release-please + GoReleaser

如需详细配置选项，请查看以下文件：

```
references/release-types.md
```
- 所有支持的语言
```
references/github-actions.md
```
- Action的输入、输出及示例
```
references/manifest-config.md
```
- 完整配置选项、插件及单体仓库相关内容

references/release-please-goreleaser-unified-workflow.md

- release-please + GoReleaser的标准联合配置方案