Skip to content

Commit 3612540

Browse files
jkongiejkongie
committed
ci: add release management with release please
Uses release please to manage the release process. Also adds a PR check workflow to lint the PR title using conventional commits.
1 parent 82a139d commit 3612540

6 files changed

Lines changed: 130 additions & 19 deletions

File tree

‎.github/workflows/conventional-commits.yml‎

Lines changed: 20 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,20 @@
1+
# Ensures that the PR follows the conventional commits specification
2+
name: pull-request-conventional
3+
4+
on:
5+
pull_request:
6+
branches: [ main ]
7+
types: [ opened, synchronize, reopened, edited ]
8+
9+
permissions:
10+
contents: read
11+
pull-requests: read
12+
13+
jobs:
14+
lint-pr-title:
15+
name: Lint PR title (Conventional Commits)
16+
runs-on: ubuntu-latest
17+
steps:
18+
- uses: amannn/action-semantic-pull-request@e32d7e603df1aa1ba07e981f2a23455dee596825 # v5
19+
env:
20+
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

‎.github/workflows/release-please.yml‎

Lines changed: 28 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,28 @@
1+
name: release-please
2+
3+
on:
4+
push:
5+
branches:
6+
- main
7+
8+
permissions:
9+
contents: write
10+
pull-requests: write
11+
id-token: write
12+
13+
jobs:
14+
release-please:
15+
name: Release Please
16+
runs-on: ubuntu-latest
17+
steps:
18+
- name: Issue GitHub Token
19+
id: issue-github-token
20+
uses: smartcontractkit/.github/actions/setup-github-token@setup-github-token/v1
21+
with:
22+
aws-role-arn: ${{ secrets.GATI_AWS_ROLE_CLD_CHANGESETS }}
23+
aws-lambda-url: ${{ secrets.GATI_LAMBDA_OPERATIONS_PLATFORM_URL }}
24+
aws-region: ${{ secrets.GATI_AWS_REGION }}
25+
26+
- uses: googleapis/release-please-action@16a9c90856f42705d54a6fda1823352bdc62cf38 # v4.4.0
27+
with:
28+
token: ${{ steps.issue-github-token.outputs.access-token }}

‎.release-please-manifest.json‎

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,3 @@
1+
{
2+
".": "0.0.1"
3+
}

‎CONTRIBUTING.md‎

Lines changed: 21 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -5,31 +5,39 @@
55
- [Contributing](#contributing)
66
- [Team Overview](#team-overview)
77
- [How to Contribute](#how-to-contribute)
8-
- [Changesets](#changesets)
8+
- [Conventional Commits](#conventional-commits)
99

1010
<!-- TOC -->
1111

1212
## Team Overview
1313

14-
The CLD team ([@smartcontractkit/operations-platform](https://github.com/orgs/smartcontractkit/teams/operations-platform)) team is responsible for the development and maintenance of this repo, and are the primary code owners and reviewers.
14+
The Operations Platform team ([@smartcontractkit/operations-platform](https://github.com/orgs/smartcontractkit/teams/operations-platform)) team is responsible for the development and maintenance of this repo, and are the primary code owners and reviewers.
1515

1616
## How to Contribute
1717

1818
1. Open a branch from `main` and give it a descriptive name.
1919
2. Make changes on your branch.
20-
3. When you are ready to submit your changes, [create a changeset](#changesets) with `pnpm changeset` and commit the changeset file.
21-
4. Push your branch and open a PR against `main`.
20+
3. Push your branch and open a PR against `main`.
21+
4. Give the PR a Conventional Commit title. This title is used by Release Please to decide the next version and changelog entry when the PR is merged.
2222
5. Ensure your PR passes all CI checks.
2323
6. Request a review from the CLD team ([@smartcontractkit/operations-platform](https://github.com/orgs/smartcontractkit/teams/operations-platform)).
2424

25-
## Changesets
25+
## Conventional Commits
2626

27-
Changesets are a way to manage changes to the codebase that are not yet released. Here are a few things to keep in mind when you create a changeset:
27+
PR titles must follow the Conventional Commits format:
2828

29-
- Following semantic versioning, select between: major, minor and patch
30-
- **MAJOR** version when you make incompatible API changes
31-
- **MINOR** version when you add functionality in a backwards compatible manner
32-
- **PATCH** version when you make backwards compatible bug fixes.
33-
- When describing the change, try to answer the following:
34-
- **WHAT** the change is
35-
- **WHY** the change was made
29+
```text
30+
<type>: <description>
31+
```
32+
33+
Release Please uses the merged PR titles on `main` to decide whether to create a release and which semantic version bump to apply:
34+
35+
- `feat: add support for new deployment workflow` creates a minor release.
36+
- `fix: handle missing workflow artifacts` creates a patch release.
37+
- `perf: reduce datastore lookup latency` creates a patch release.
38+
- `feat!: remove deprecated workflow input` creates a major release.
39+
- `docs: update release instructions`, `test: add workflow deploy coverage`, `ci: update pull request checks`, `chore: update dependencies`, `build: update go version`, `style: format generated code`, and `refactor: simplify deploy input handling` are allowed but usually do not create a release by themselves.
40+
41+
Use `!` after the type, or include `BREAKING CHANGE:` in the commit body, when the change is incompatible with existing users.
42+
43+
For details on how Release Please uses Conventional Commits and semantic versioning, see [RELEASE.md](./RELEASE.md).

‎RELEASE.md‎

Lines changed: 36 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -3,17 +3,47 @@
33
<!-- TOC -->
44

55
- [Release Process](#release-process)
6+
- [Release Please](#release-please)
7+
- [Semantic Versioning](#semantic-versioning)
68
- [Preparing a Release](#preparing-a-release)
79
- [How to Release](#how-to-release)
810

911
<!-- TOC -->
1012

11-
### Preparing a Release
13+
## Release Please
1214

13-
After every PR with a changeset is merged, a changesets CI job will create or update a "Version Packages" PR, which contains the release version and information about the changes.
15+
This repo uses [Release Please](https://github.com/googleapis/release-please) to manage releases. Do not run `pnpm changeset` or add changeset files for releases.
1416

15-
### How to Release
17+
Release Please determines the next release from Conventional Commit messages on `main`. Because PR titles are linted, use a Conventional Commit title that describes the user-visible impact of the change:
1618

17-
1. Approve or request approval to merge the "Version Packages" PR.
18-
2. Merge the "Version Packages" PR.
19-
3. This will trigger the release workflow, automatically releasing a new version and pushing a tag for the version. Check the [release view](https://github.com/smartcontractkit/chainlink-deployments-framework/releases) to confirm the latest release.
19+
- `feat: add support for new deployment workflow` for backwards-compatible features
20+
- `fix: handle missing workflow artifacts` for backwards-compatible bug fixes
21+
- `perf: reduce datastore lookup latency` for performance improvements
22+
- `feat!: remove deprecated workflow input` or a commit body with `BREAKING CHANGE:` for incompatible API changes
23+
24+
Other types such as `docs`, `test`, `ci`, `chore`, `build`, `style`, and `refactor` are allowed, but they are hidden from the changelog by the current Release Please configuration and usually do not create a release by themselves.
25+
26+
When writing the PR title and description, make it clear:
27+
28+
- **WHAT** the change is
29+
- **WHY** the change was made
30+
- Whether the change is breaking or requires downstream action
31+
32+
## Semantic Versioning
33+
34+
Release Please follows semantic versioning when choosing the next version:
35+
36+
- **MAJOR** version when you make incompatible API changes
37+
- **MINOR** version when you add functionality in a backwards-compatible manner
38+
- **PATCH** version when you make backwards-compatible bug fixes
39+
40+
## Preparing a Release
41+
42+
The `release-please` workflow runs after changes are merged to `main`. When Release Please finds releasable changes, it opens or updates a release PR that includes the version bump, changelog updates, and `.release-please-manifest.json` changes.
43+
44+
## How to Release
45+
46+
1. Review the Release Please PR and confirm the changelog and version are correct.
47+
2. Approve or request approval to merge the Release Please PR.
48+
3. Merge the Release Please PR into `main`.
49+
4. The `release-please` workflow will create the GitHub release and push the version tag automatically.

‎release-please-config.json‎

Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,22 @@
1+
{
2+
"packages": {
3+
".": {
4+
"release-type": "go",
5+
"package-name": "cld-changesets",
6+
"bump-minor-pre-major": true
7+
}
8+
},
9+
"changelog-sections": [
10+
{ "type": "build", "section": "Builds", "hidden": true },
11+
{ "type": "chore", "section": "Miscellaneous", "hidden": true },
12+
{ "type": "ci", "section": "Continuous Integrations", "hidden": true },
13+
{ "type": "docs", "section": "Documentation", "hidden": true },
14+
{ "type": "feat", "section": "Features" },
15+
{ "type": "fix", "section": "Bug Fixes" },
16+
{ "type": "perf", "section": "Performance Improvements", "bump": "patch" },
17+
{ "type": "refactor", "section": "Code Refactoring", "hidden": true },
18+
{ "type": "revert", "section": "Reverts", "bump": "patch" },
19+
{ "type": "style", "section": "Styles", "hidden": true },
20+
{ "type": "test", "section": "Tests", "hidden": true }
21+
]
22+
}

0 commit comments

Comments
 (0)