feat: release automation configs #291
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| @@ -0,0 +1,40 @@ | ||||||||||
| name: release-please | ||||||||||
|
|
||||||||||
| permissions: | ||||||||||
| contents: write | ||||||||||
| pull-requests: write | ||||||||||
|
|
||||||||||
| 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 | ||||||||||
|
There was a problem hiding this comment. 🧩 Analysis chain🏁 Script executed: cat -n .github/workflows/release-please.yml | head -40Repository: openfga/go-sdk Length of output: 1381 🌐 Web query:
💡 Result: For GitHub Actions reusable workflows, the security best practice is to pin to a full-length commit SHA rather than using a branch like 'main'. This prevents supply chain attacks where a malicious actor with repository access could push malicious changes to the branch, causing all callers to execute compromised code. Pinning to SHA ensures immutability: the specific workflow version at that commit is used, and changes require generating a SHA-1 collision, which is computationally infeasible. Using branches or tags is riskier because they are mutable—branches receive new commits, and tags can be retargeted or deleted by repository owners. Official GitHub documentation explicitly states the same principles for reusable workflows as for actions: "The same principles described above for using third-party actions also apply to using third-party workflows" (where "above" includes "Pin actions to a full-length commit SHA"). It also notes: "If you use a commit SHA when referencing the reusable workflow, you can ensure that everyone who reuses that workflow will always be using the same YAML code. However, if you reference a reusable workflow by a tag or branch, be sure that you can trust that version of the workflow." Syntax examples: - SHA pin (recommended): uses: org/repo/.github/workflows/my-workflow.yml@abc123... - Branch (avoid for security): uses: org/repo/.github/workflows/my-workflow.yml@main Additional best practices: - Use Dependabot or Renovate to automate updates to new pinned SHAs. - For same-repo reusable workflows, ./.github/workflows/my-workflow.yml uses the same ref as the caller (safe for internal use). - Enforce SHA pinning via GitHub's "allowed actions and reusable workflows" policies at repo/org/enterprise level (new feature as of Aug 2025). - Audit reusable workflow source code and limit permissions. This aligns with GitHub's security hardening guide and recent policy updates supporting SHA enforcement for both actions and reusable workflows. Citations:
Pin reusable workflow to a commit SHA instead of Using a mutable branch reference for release automation introduces supply-chain risk. GitHub's security hardening guide recommends pinning reusable workflows to a full-length commit SHA to prevent malicious changes. Pin to a specific SHA and rotate intentionally via automation (e.g., Dependabot). 🤖 Prompt for AI Agents |
||||||||||
| with: | ||||||||||
| bump-type: ${{ inputs.bump-type || 'auto' }} | ||||||||||
| release-version: ${{ inputs.release-version || '' }} | ||||||||||
|
Comment on lines
+36
to
+37
There was a problem hiding this comment. This workflow runs on both
Suggested change
|
||||||||||
| 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.7.5" | ||
| } |
| 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
There was a problem hiding this comment. The intro says the project uses a |
||||||
|
|
||||||
| --- | ||||||
|
|
||||||
| ## 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.7.0` → `0.8.0` | | ||||||
| | Everything else | **Patch** (`0.0.x`) | `0.7.5` → `0.7.6` | | ||||||
|
|
||||||
| 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.8.0` or `0.8.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.7.5` + patch = `0.7.6`), 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.7.5-beta.1`, release-please tracks the | ||||||
| base semver (`0.7.5`) but cannot reliably decide whether the next release should be | ||||||
| `0.7.5`, `0.7.6`, or `0.8.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.8.0-beta.1 → explicit: 0.8.0-beta.2 → explicit: 0.8.0 | ||||||
| ``` | ||||||
|
Comment on lines
+64
to
+66
There was a problem hiding this comment. Add language identifiers to fenced code blocks. Two fenced blocks are missing language tags, which triggers markdownlint (MD040). 📝 Proposed fix-```
+```text
0.8.0-beta.1 → explicit: 0.8.0-beta.2 → explicit: 0.8.0... Also applies to: 75-82 🧰 Tools🪛 markdownlint-cli2 (0.22.0)[warning] 64-64: Fenced code blocks should have a language specified (MD040, fenced-code-language) 🤖 Prompt for AI Agents |
||||||
|
|
||||||
| --- | ||||||
|
|
||||||
| ## 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) | ||||||
|
There was a problem hiding this comment. The changelog mapping examples mark
Suggested change
|
||||||
| chore: bump dependencies → (hidden) | ||||||
|
Comment on lines
+80
to
+81
There was a problem hiding this comment. Changelog example is out of sync with actual config for This doc says 🤖 Prompt for AI Agents |
||||||
| ``` | ||||||
|
|
||||||
| --- | ||||||
|
|
||||||
| ## Troubleshooting | ||||||
|
|
||||||
| **"Invalid previous_tag parameter" error.** | ||||||
| The manifest version does not have a corresponding GitHub Release object. Reset the | ||||||
| manifest to the last valid tag: | ||||||
| ```bash | ||||||
| echo '{ ".": "0.x.y" }' > .release-please-manifest.json | ||||||
| git commit -am "chore: reset manifest to v0.x.y" | ||||||
| git push origin main | ||||||
| ``` | ||||||
|
|
||||||
| **Duplicate release PRs.** | ||||||
| Close all stale ones. The workflow auto-closes stale open PRs on each dispatch, but | ||||||
| merged duplicates need manual labelling with `autorelease: tagged`. | ||||||
|
|
||||||
| **Changelog shows everything ungrouped.** | ||||||
| Make sure `changelog-type` in `release-please-config.json` is set to `"default"`, not | ||||||
| `"github"`. | ||||||
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -14,7 +14,7 @@ package constants | |||||
|
|
||||||
| const ( | ||||||
| // SdkVersion is the version of the OpenFGA Go SDK. | ||||||
| SdkVersion = "0.7.5" // x-release-please-version | ||||||
|
|
||||||
| // UserAgent is the user agent used in HTTP requests. | ||||||
| UserAgent = "openfga-sdk go/0.7.5" | ||||||
|
There was a problem hiding this comment.
Suggested change
|
||||||
|
|
||||||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,27 @@ | ||
| { | ||
| "$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json", | ||
| "release-type": "go", | ||
| "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": "generic", "path": "internal/constants/constants.go" } | ||
| ] | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This workflow references a reusable workflow with
@main. To avoid unexpected breakages and reduce supply-chain risk, pin the reusable workflow reference to an immutable ref (tag or commit SHA), consistent with the rest of the repo’s workflows.