-
Notifications
You must be signed in to change notification settings - Fork 25
feat: release automation configs #362
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,36 @@ | ||
| name: release-please | ||
|
|
||
| on: | ||
| push: | ||
| branches: [main] | ||
| workflow_dispatch: | ||
| inputs: | ||
| bump-type: | ||
| description: > | ||
| Version bump type. Select 'explicit' to supply an exact version via | ||
| the 'release-version' field below. Select 'auto' to let | ||
| conventional-commits determine the bump automatically. | ||
| required: false | ||
| type: choice | ||
| default: 'auto' | ||
| options: | ||
| - auto | ||
| - patch | ||
| - minor | ||
| - major | ||
| - explicit | ||
| release-version: | ||
| description: > | ||
| Explicit version to release (e.g. 1.2.3 or 1.4.0-beta.1). | ||
| required: false | ||
| type: string | ||
|
|
||
| jobs: | ||
| release: | ||
| uses: openfga/sdk-generator/.github/workflows/release-please.yml@main | ||
| with: | ||
| bump-type: ${{ inputs.bump-type || 'auto' }} | ||
| release-version: ${{ inputs.release-version || '' }} | ||
| secrets: | ||
| APP_ID: ${{ secrets.APP_ID }} | ||
| APP_PRIVATE_KEY: ${{ secrets.APP_PRIVATE_KEY }} | ||
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,3 @@ | ||||||
| { | ||||||
| ".": "0.9.3" | ||||||
|
||||||
| ".": "0.9.3" | |
| ".": "0.9.4" |
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,103 @@ | ||||||
| # Release guide | ||||||
|
|
||||||
| This project uses [release-please](https://github.com/googleapis/release-please) via a | ||||||
| `workflow_dispatch`-triggered GitHub Actions workflow. This document explains how to cut | ||||||
| a release and what to watch out for. | ||||||
|
Comment on lines
+3
to
+5
|
||||||
|
|
||||||
| --- | ||||||
|
|
||||||
| ## Versioning rules for this project | ||||||
|
|
||||||
| We are pre-1.0.0. Semver conventions are relaxed: | ||||||
|
|
||||||
| | Change type | Bump | Example | | ||||||
| |--- |--- |--- | | ||||||
| | Breaking change | **Minor** (`0.x.0`) | `0.9.0` → `0.10.0` | | ||||||
| | Everything else | **Patch** (`0.0.x`) | `0.9.3` → `0.9.4` | | ||||||
|
|
||||||
| Major bumps (`1.0.0`) are reserved for a deliberate stable-API graduation decision — not for | ||||||
| routine breaking changes. | ||||||
|
|
||||||
| --- | ||||||
|
|
||||||
| ## Cutting a release | ||||||
|
|
||||||
| 1. Go to **Actions → release-please** and click **Run workflow**. | ||||||
| 2. Choose a bump type: | ||||||
| - `patch` — bugfixes, docs, small changes | ||||||
| - `minor` — breaking changes (see above) | ||||||
| - `explicit` — you specify the exact version string (e.g. `0.10.0` or `0.10.0-beta.1`) | ||||||
| 3. The workflow creates a release PR. Review it, then merge. | ||||||
| 4. The GitHub Release and tag are created automatically on merge. | ||||||
|
|
||||||
| > **Note — release-please only understands `auto` or an explicit version string.** | ||||||
| > The `patch`, `minor`, and `major` options in the workflow dropdown are conveniences | ||||||
| > implemented in the workflow. The workflow reads the current manifest version, computes | ||||||
| > the next version (e.g. `0.9.3` + patch = `0.9.4`), and passes that computed string | ||||||
| > to release-please as an explicit `Release-As:` commit — exactly the same as choosing | ||||||
| > `explicit` and typing it yourself. There is no native patch/minor/major mode in | ||||||
| > release-please. This is why `explicit` is always the safest option when in doubt — | ||||||
| > you are just skipping the arithmetic step. | ||||||
|
|
||||||
| --- | ||||||
|
|
||||||
| ## When to use `explicit` | ||||||
|
|
||||||
| Use `explicit` and type the version yourself in any of these situations: | ||||||
|
|
||||||
| **After a beta or non-conventional tag.** | ||||||
| If the previous release was something like `0.9.3-beta.1`, release-please tracks the | ||||||
| base semver (`0.9.3`) but cannot reliably decide whether the next release should be | ||||||
| `0.9.3`, `0.9.4`, or `0.10.0`. It will often guess wrong. | ||||||
|
|
||||||
| The rule of thumb: **if the last tag had a pre-release suffix, always use `explicit` for | ||||||
| the next release.** | ||||||
|
|
||||||
| **After a manually created tag.** | ||||||
| Any tag created outside of the release-please workflow (e.g. hotfixes, manual git tags) | ||||||
| is invisible to release-please's version logic. Use `explicit` to anchor the next version | ||||||
| correctly. | ||||||
|
|
||||||
| **When you want a beta.** | ||||||
| Release-please does not increment pre-release suffixes automatically. Use `explicit` for | ||||||
| every beta, incrementing the suffix manually: | ||||||
| ``` | ||||||
| 0.10.0-beta.1 → explicit: 0.10.0-beta.2 → explicit: 0.10.0 | ||||||
| ``` | ||||||
|
|
||||||
| --- | ||||||
|
|
||||||
| ## What goes in the changelog | ||||||
|
|
||||||
| Commit messages must follow [Conventional Commits](https://www.conventionalcommits.org/) | ||||||
| for release-please to group them correctly: | ||||||
|
|
||||||
| ``` | ||||||
| feat: add support for batch check → Added | ||||||
| fix: correct retry logic for transient errors → Fixed | ||||||
| docs: update API reference → Documentation | ||||||
| perf: cache DNS lookups → Changed | ||||||
| refactor: extract auth helper → (hidden) | ||||||
|
||||||
| refactor: extract auth helper → (hidden) | |
| refactor: extract auth helper → Changed |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,28 @@ | ||
| { | ||
| "$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json", | ||
| "release-type": "node", | ||
| "packages": { | ||
| ".": { | ||
| "include-component-in-tag": false, | ||
| "changelog-path": "CHANGELOG.md", | ||
| "changelog-type": "default", | ||
| "bump-minor-pre-major": true, | ||
| "bump-patch-for-minor-pre-major": true, | ||
| "changelog-sections": [ | ||
| { "type": "feat", "section": "Added", "hidden": false }, | ||
| { "type": "fix", "section": "Fixed", "hidden": false }, | ||
| { "type": "perf", "section": "Changed", "hidden": false }, | ||
| { "type": "refactor", "section": "Changed", "hidden": false }, | ||
| { "type": "revert", "section": "Removed", "hidden": false }, | ||
| { "type": "docs", "section": "Documentation", "hidden": false }, | ||
| { "type": "test", "section": "Tests", "hidden": true }, | ||
| { "type": "ci", "section": "CI", "hidden": true }, | ||
| { "type": "chore", "section": "Miscellaneous", "hidden": true } | ||
| ], | ||
| "extra-files": [ | ||
| { "type": "json", "path": "package.json", "jsonpath": "$.version" }, | ||
| { "type": "generic", "path": "constants/index.ts" } | ||
| ] | ||
| } | ||
| } | ||
| } |
Check warning
Code scanning / CodeQL
Workflow does not contain permissions Medium
Copilot Autofix
AI 5 days ago
In general, fix this by adding an explicit
permissions:block that grants only the scopes needed for the workflow to operate, either at the workflow root (applies to all jobs) or under the specific job. Because this workflow solely delegates to a reusable workflow that likely performs release operations (tagging, creating GitHub releases, etc.), we should start from a safe minimal set and then allow contents write access so releases and tags can be created while keeping other scopes at their default (none).The best minimally invasive fix is to add a
permissions:block at the top level, just after theon:trigger, to constrain theGITHUB_TOKENfor all jobs in this workflow (there is only one job,release). A conservative configuration for a release workflow is:This assumes the reusable workflow needs to create/update releases or tags (which is standard for release-please). If the project later finds this is too strong, they can refine it further, but this is the smallest reasonable change that addresses the CodeQL warning and maintains expected behavior. Concretely, edit
.github/workflows/release-please.ymlto insert thepermissions:block between theon:section (ending at line 26–27) and thejobs:section (line 28). No additional imports or dependencies are required.