You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: drive releases from a single GitHub Actions workflow
Replaces the previous two-workflow setup (push a tag, separate publish workflow listens for it) with a single end-to-end `Release` workflow at `.github/workflows/release.yml`. The old `publish-release-from-tag.yml` is removed.
Flow:
1. Actions → Release → Run workflow with `version=vX.Y.Z` (optional `ref`, defaults to `main`).
2. The job runs in the protected `release` GitHub Environment, which holds the Sonatype / GPG secrets and requires reviewer approval before anything happens.
3. After approval, the workflow validates semver, runs `./gradlew check` on the chosen ref, creates and pushes the annotated tag `vX.Y.Z`, checks out the tag, re-runs `./gradlew check`, builds artifacts, creates the GitHub Release with the SDK / agent / OTel extension jars attached, publishes to Maven Central via Sonatype, and polls Maven Central until the version is visible.
Because publishing happens in the same workflow as the tag push, the tag push no longer needs to retrigger anything. The default `GITHUB_TOKEN` is sufficient — no GitHub App / PAT is required.
Re-publish path: re-run `Release` with the same version. The workflow detects an existing tag, skips the tag-creation step, and resumes from build/publish. GitHub Release asset uploads use `--clobber` so partial uploads from a prior failed run are replaced.
The environment name is intentionally generic (`release`) rather than maven-central-specific because the gated job covers the full release flow — tag creation, GitHub Release, Sonatype publish, and Maven Central sync wait — not just the Sonatype step.
`CONTRIBUTING.md` gains a Releasing section documenting the end-to-end flow, the approval gate, the re-publish behavior, the scoped environment secrets, and a note that there is no version constant to bump in source because the version is derived from git tags at build time by `generateVersion()` in `build.gradle`.
`scripts/release.sh` is retained as a local fallback.
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+31Lines changed: 31 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,6 +17,37 @@ Because the SDK is new and under active development, third-party contribution be
17
17
- These hooks automatically run common checks for you but CI also runs the same checks before merging to the main branch is allowed
18
18
- NOTE: this will overwrite existing hooks. Take backups before running
19
19
20
+
## Releasing
21
+
22
+
Releases are driven end-to-end from a single GitHub Actions workflow. You do not need to tag locally or push tags from your machine.
23
+
24
+
To cut a release:
25
+
26
+
1. Make sure everything you want included is merged to `main` and CI is green.
27
+
2. Go to **Actions → Release → Run workflow**.
28
+
3. Enter the version as `vX.Y.Z` (semver, no `-SNAPSHOT`). Leave `ref` as `main` unless you have a specific reason to tag a different commit.
29
+
4. The job runs in the protected `release` GitHub Environment and will pause for **required-reviewer approval** before doing anything. Approve from the workflow run page (or the repo's Deployments tab).
30
+
5. Once approved, the `Release` workflow will, in one job:
31
+
- Validate the version.
32
+
- Check out the chosen ref and run `./gradlew check`.
33
+
- Create and push the annotated tag `vX.Y.Z` (using the default `GITHUB_TOKEN` — no separate bot identity is needed since the publish steps are in the same workflow).
34
+
- Check out the tag, re-run `./gradlew check`, and build release artifacts.
35
+
- Create the GitHub Release with the SDK, agent, and OTel extension jars attached.
36
+
- Publish to Maven Central via Sonatype, signed with the project GPG key.
37
+
- Poll Maven Central until the new version is visible (this can take many hours).
38
+
39
+
The Sonatype and GPG signing secrets (`SONATYPE_USERNAME`, `SONATYPE_PASSWORD`, `GPG_SIGNING_KEY`, `GPG_SIGNING_PASSWORD`) are scoped to the `release` environment.
40
+
41
+
The SDK version is computed from git tags at build time (see `generateVersion()` in `build.gradle`) and embedded into `braintrust.properties`, so there are no version constants to bump in source.
42
+
43
+
### Re-publishing a failed release
44
+
45
+
If the workflow fails partway through, re-run **Release** with the same version. The workflow detects that the tag already exists, skips tag creation, and resumes from the build/publish steps against the existing tag. GitHub Release asset uploads use `--clobber` so partial uploads from a prior run are replaced.
46
+
47
+
### Local fallback
48
+
49
+
`scripts/release.sh` can still create and push a tag from a clean local checkout if the Actions-driven flow is unavailable. Prefer the workflow.
0 commit comments