Skip to content

Commit 5fb550d

Browse files
authored
chore(ci): add pre-release lane on develop branch (#440)
ci: add self-contained experimental pre-release lane on develop Adds .github/workflows/release-please-develop.yml: a standalone workflow_dispatch + push(develop) flow that cuts pre-release-only versions (alpha/beta/rc) via release-please, GPG-signed tags and draft pre-releases. It does NOT modify or call the shared openfga/.github release-please workflow, so the stable main flow is untouched. Publishing is handled by the existing main.yaml tag trigger. Documents the develop-upstream branch model in RELEASE.md.
1 parent 6066c68 commit 5fb550d

2 files changed

Lines changed: 125 additions & 2 deletions

File tree

Lines changed: 52 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,52 @@
1+
name: release-please-develop
2+
3+
# Experimental / pre-release lane for the `develop` branch.
4+
#
5+
# This is a thin caller around the SHARED reusable workflow
6+
# openfga/.github/.github/workflows/release-please-prerelease.yml. The common
7+
# logic lives there so every SDK can onboard by copying just this file.
8+
#
9+
# It is completely separate from release-please.yml (the stable main flow):
10+
# * targets the long-lived `develop` branch
11+
# * only ever cuts pre-release versions (alpha/beta/rc) — enforced by the
12+
# reusable workflow. Stable releases must go through main.
13+
#
14+
# Triggers:
15+
# * workflow_dispatch → build a release PR for an explicit pre-release version
16+
# * push to develop → when the `release:` PR merges, tag + draft + publish
17+
18+
permissions:
19+
contents: read
20+
21+
on:
22+
push:
23+
branches: [develop]
24+
workflow_dispatch:
25+
inputs:
26+
release-version:
27+
description: >
28+
Explicit pre-release version to cut (e.g. 0.10.0-beta.1, 0.10.0-rc.2).
29+
Must include an alpha/beta/rc suffix. Stable versions are rejected.
30+
required: true
31+
type: string
32+
33+
jobs:
34+
prerelease:
35+
permissions:
36+
contents: write
37+
pull-requests: write
38+
if: |
39+
github.event_name == 'workflow_dispatch' ||
40+
startsWith(github.event.head_commit.message, 'release:')
41+
uses: openfga/.github/.github/workflows/release-please-prerelease.yml@main
42+
with:
43+
trigger-event: ${{ github.event_name }}
44+
release-version: ${{ inputs.release-version || '' }}
45+
base-branch: develop
46+
staging-branch: release-develop
47+
secrets:
48+
RELEASER_APP_CLIENT_ID: ${{ secrets.RELEASER_APP_CLIENT_ID }}
49+
RELEASER_APP_PRIVATE_KEY: ${{ secrets.RELEASER_APP_PRIVATE_KEY }}
50+
GPG_PRIVATE_KEY: ${{ secrets.GPG_PRIVATE_KEY }}
51+
GPG_PASSPHRASE: ${{ secrets.GPG_PASSPHRASE }}
52+

RELEASE.md

Lines changed: 73 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -83,15 +83,86 @@ chore: bump dependencies → (hidden)
8383

8484
---
8585

86+
## Experimental releases from `develop`
87+
88+
For pre-release builds (beta/rc) of code that isn't on `main` yet, use the
89+
separate `release-please-develop` workflow. It targets `develop`, only cuts
90+
pre-release versions, and never touches the stable `main` flow. (It's a thin
91+
caller around the shared `openfga/.github` `release-please-prerelease.yml`, so
92+
other SDKs can reuse it.)
93+
94+
`develop` is upstream of `main`:
95+
96+
```
97+
develop ●──────●──────● (0.10.0-beta.1, -beta.2, -rc.1)
98+
\ \ promote the code via a normal PR
99+
main ──────●─────────────● (0.10.0)
100+
```
101+
102+
**Promote code, not release commits.** Move features `develop → main` with a
103+
normal PR. Never merge `develop`'s manifest/CHANGELOG bumps into `main` — they
104+
set `main` to a pre-release version and break release-please there.
105+
106+
> If the code is already on `main`, you don't need `develop` — cut the beta from
107+
> `main` with `release-please` using `explicit` (e.g. `0.10.0-beta.1`).
108+
109+
### Cutting a beta
110+
111+
1. Land the code on `develop`.
112+
2. **Actions → release-please-develop → Run workflow**, enter an explicit
113+
pre-release version (e.g. `0.10.0-beta.1`; stable versions are rejected).
114+
3. Merge the release PR it opens against `develop`. A signed `v0.10.0-beta.1`
115+
tag is pushed and published to npm under the `beta` dist-tag (`npm i @openfga/sdk@beta`).
116+
117+
```text
118+
┌─────────────────────────────────────────────┐
119+
│ Run workflow → version: 0.10.0-beta.1 │
120+
└─────────────────────────────────────────────┘
121+
122+
123+
stage "Release-As" commit on release-develop
124+
125+
126+
release-please opens a release PR
127+
128+
▼ (auto) retargeted to develop
129+
┌──────────────┐
130+
│ you merge it │
131+
└──────────────┘
132+
133+
134+
signed tag v0.10.0-beta.1 + draft pre-release
135+
136+
137+
main.yaml publishes → npm dist-tag: beta
138+
139+
140+
release-develop reset to develop (next cycle)
141+
```
142+
143+
> `release-develop` is an internal scratch branch the workflow manages and
144+
> resets each run — you never touch it. Your only branch is `develop`.
145+
146+
### Graduating to stable
147+
148+
Promote the code to `main` via a normal PR, then release `0.10.0` on `main` with
149+
`release-please` using `explicit`. To realign `develop` afterward, open a normal
150+
`main → develop` PR — both branches are protected, so this stays a reviewed merge
151+
(no force-pushes, no direct pushes).
152+
153+
---
154+
86155
## Troubleshooting
87156

88157
**"Invalid previous_tag parameter" error.**
89158
The manifest version does not have a corresponding GitHub Release object. Reset the
90-
manifest to the last valid tag:
159+
manifest to the last valid tag via a PR (`main` is protected, so no direct push):
91160
```bash
161+
git checkout -b fix/reset-manifest
92162
echo '{ ".": "0.x.y" }' > .release-please-manifest.json
93163
git commit -am "chore: reset manifest to v0.x.y"
94-
git push origin main
164+
git push origin fix/reset-manifest
165+
# then open and merge a PR into main
95166
```
96167

97168
**Duplicate release PRs.**

0 commit comments

Comments
 (0)