Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit ffa485c

Browse files
feat(ci): Add release-please automation with VERSION (#2622)
* Add VERSION file that Zephyr will pick up * Add release-please automation * Updated docs on commits messages, and PR process * Updated PR template to match. --- Release-As: 0.1.0 Co-authored-by: Cem Aksoylar <[email protected]>
1 parent 7054299 commit ffa485c

8 files changed

Lines changed: 112 additions & 20 deletions

File tree

.github/pull_request_template.md

Lines changed: 5 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -1,15 +1,8 @@
1-
<!-- If you're adding a board/shield please fill out this check-list, otherwise you can delete it -->
1+
<!-- Note: ZMK is generally not accepting PRs for new keyboards. New generic controller PRs *may* still be accepted, please discuss on the Discord server first. -->
22

3-
## Board/Shield Check-list
3+
## PR check-list
44

5-
- [ ] This board/shield is tested working on real hardware
6-
- [ ] Definitions follow the general style of other shields/boards upstream ([Reference](https://zmk.dev/docs/development/new-shield))
7-
- [ ] `.zmk.yml` metadata file added
5+
- [ ] Branch has a [clean commit history](https://zmk.dev/docs/development/contributing/pull-requests#clean-commit-history)
6+
- [ ] Additional tests are included, if changing behaviors/core code that is testable.
87
- [ ] Proper Copyright + License headers added to applicable files (Generally, we stick to "The ZMK Contributors" for copyrights to help avoid churn when files get edited)
9-
- [ ] General consistent formatting of DeviceTree files
10-
- [ ] Keymaps do not use deprecated key defines (Check using the [upgrader tool](https://zmk.dev/docs/codes/keymap-upgrader))
11-
- [ ] `&pro_micro` used in favor of `&pro_micro_d/a` if applicable
12-
- [ ] If split, no name added for the right/peripheral half
13-
- [ ] Kconfig.defconfig file correctly wraps _all_ configuration in conditional on the shield symbol
14-
- [ ] `.conf` file has optional extra features commented out
15-
- [ ] Keyboard/PCB is part of a shipped group buy or is generally available in stock to purchase (OSH/personal projects without general availability should create a zmk-config repo instead)
8+
- [ ] [Pre-commit](https://zmk.dev/docs/development/local-toolchain/pre-commit) used to check formatting of files, commit messages, etc.
Lines changed: 38 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,38 @@
1+
on:
2+
push:
3+
branches:
4+
- main
5+
- "v*.*-branch"
6+
7+
permissions:
8+
contents: write
9+
pull-requests: write
10+
11+
name: release-please
12+
13+
jobs:
14+
release-please:
15+
runs-on: ubuntu-latest
16+
steps:
17+
- uses: googleapis/release-please-action@v4
18+
id: release
19+
with:
20+
token: ${{ secrets.ZMK_RELEASE_PLEASE_TOKEN }}
21+
target-branch: ${{ github.ref_name }}
22+
- uses: actions/checkout@v4
23+
if: ${{ steps.release.outputs.release_created }}
24+
- name: create major, minor branch
25+
if: ${{ steps.release.outputs.release_created && steps.release.outputs.patch == '0' }}
26+
run: |
27+
git remote add gh-token-branch "https://x-access-token:${{ secrets.ZMK_RELEASE_PLEASE_TOKEN }}@github.com/${{ github.repository }}.git"
28+
git checkout -b v${{ steps.release.outputs.major }}.${{ steps.release.outputs.minor }}-branch
29+
git push gh-token-branch v${{ steps.release.outputs.major }}.${{ steps.release.outputs.minor }}-branch
30+
- name: tag major and minor versions
31+
if: ${{ steps.release.outputs.release_created }}
32+
run: |
33+
git config user.name github-actions[bot]
34+
git config user.email 41898282+github-actions[bot]@users.noreply.github.com
35+
git remote add gh-token "https://x-access-token:${{ secrets.ZMK_RELEASE_PLEASE_TOKEN }}@github.com/${{ github.repository }}.git"
36+
git tag -d v${{ steps.release.outputs.major }}.${{ steps.release.outputs.minor }} || true
37+
git tag -a v${{ steps.release.outputs.major }}.${{ steps.release.outputs.minor }} -m "Release v${{ steps.release.outputs.major }}.${{ steps.release.outputs.minor }}"
38+
git push --force gh-token v${{ steps.release.outputs.major }}.${{ steps.release.outputs.minor }}

.pre-commit-config.yaml

Lines changed: 6 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -16,7 +16,12 @@ repos:
1616
rev: v2.7.1
1717
hooks:
1818
- id: prettier
19-
exclude: ".git/COMMIT_EDITMSG"
19+
exclude: |
20+
(?x)^(
21+
.git/COMMIT_EDITMSG|
22+
CHANGELOG.md|
23+
.release-please-manifest.json
24+
)$
2025
# Workaround for https://github.com/pre-commit/mirrors-prettier/issues/29
2126
additional_dependencies:
2227

.release-please-manifest.json

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
{}

app/VERSION

Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,13 @@
1+
# x-release-please-start-major
2+
VERSION_MAJOR = 0
3+
# x-release-please-end
4+
5+
# x-release-please-start-minor
6+
VERSION_MINOR = 0
7+
# x-release-please-end
8+
9+
# x-release-please-start-patch
10+
PATCHLEVEL = 1
11+
# x-release-please-end
12+
13+
VERSION_TWEAK = 0

docs/docs/development/contributing/commit-messages.md renamed to docs/docs/development/contributing/pull-requests.md

Lines changed: 39 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1,12 +1,26 @@
11
---
2-
title: Commit Messages
2+
title: Pull Requests
33
---
44

5+
Changes to ZMK's `main` branch are all done through pull requests, even for core committers. The following will help ensure an easier PR/review process for all involved.
6+
7+
## Clean Commit History
8+
9+
Before opening a PR, ensure your branch has a clean commit history, which allows our release automation to generate clean changelogs, and allows easier understanding of our commit history when investigating regressions, etc.
10+
11+
A "clean" commit history satisfies the following:
12+
13+
- Commit messages follow our [commit message conventions](#commit-messages).
14+
- The sequence of commits should be well organized, with discrete commits used to break any combined work into smaller, cohesive changes if the scope of a given PR/change is larger. This allows for easier code review. You can usually accomplish this by amending (e.g. `git add foo && git commit --amend`) or by interactive rebasing (e.g. `git rebase -i upstream/main`) and squashing/rewording commits.
15+
- Do not use merge commits to catch up with ZMK `main`, instead using rebasing to address any issues with divergence (e.g. `git rebase upstream/main`).
16+
17+
### Commit Messages
18+
519
The ZMK project uses [conventional commits](https://www.conventionalcommits.org/) for their commit messages. This not only provides consistency for our commits, but also allows for release/versioning automation to determine the next version to release, generating changelogs, etc.
620

721
Commit messages will be checked as part of our CI process by GitHub Actions.
822

9-
## Guidelines
23+
#### Guidelines
1024

1125
Commits should have the following:
1226

@@ -16,7 +30,7 @@ Commits should have the following:
1630
- A body that provides more detail of the changes. This _may_ be a bulleted list or paragraph prose.
1731
- An optional set of [git trailers](https://git-scm.com/docs/git-interpret-trailers#_description) for things like [GitHub keywords](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests) following a blank line.
1832

19-
## Example
33+
#### Example
2034

2135
Here is an example of a good commit message:
2236

@@ -34,11 +48,11 @@ Other layouts exist, such as "southpaw" horizontally mirrored layouts,
3448
and layouts with a fifth column, but those seem to be much less common.
3549
```
3650

37-
## Pre-Commit
51+
#### Pre-Commit
3852

3953
To help make sure you don't need to wait for GitHub Actions to check your commits, you can [set up pre-commit](../local-toolchain/pre-commit.md) to check your commits as you create them.
4054

41-
## Types
55+
#### Types
4256

4357
The following commit types are used by ZMK:
4458

@@ -51,7 +65,7 @@ The following commit types are used by ZMK:
5165
- `ci:` -- changes to our continuous integration setup with GitHub Actions, usually only for the files in `.github/workflows/`
5266
- `chore:` -- grab bag type for small changes that don't fall into any of the above categories, including dependency updates for development tools and docs.
5367

54-
## Scopes
68+
#### Scopes
5569

5670
The following scopes are frequently used to further clarify the scope of the change:
5771

@@ -68,3 +82,22 @@ The following scopes are frequently used to further clarify the scope of the cha
6882
- `core` -- changes to any other area of our core code
6983
- `boards` -- changes to the in-tree boards
7084
- `shields` -- changes to the in-tree shields
85+
86+
## Opening a PR
87+
88+
Create a PR by visiting https://github.com/zmkfirmware/zmk/pulls and clicking "New pull request" and selecting your branch. GitHub should auto-populate a start of a description/body to your PR, but please make sure to supplement that with additional details about the change and make sure the check-list is complete in the PR template.
89+
90+
Once created, the PR should automatically have reviewers assigned.
91+
92+
## Review
93+
94+
Depending on the area of change, different ZMK team members will review the PR. The ZMK project is a small team, so please be patient with the review timeline. You are welcome to send a polite request/nudge on our Discord server to draw attention to your PR if it has not gotten a response after a reasonable amount of time.
95+
96+
## Merging
97+
98+
Maintainers merging PRs will perform the following steps:
99+
100+
1. Verify that the expected tests have all run, and are passing
101+
1. Inspect the commits in the PR to confirm the commit messages not only are proper conventional commits, but have accurate descriptions and are using the correct type for the set of files changed by the commit(s).
102+
1. Merge the PR using a squash-merge. If the PR includes multiple commits, then the squash message will be fixed up manually to remove the `* ` prefixes from each message section to ensure [release-please](https://github.com/googleapis/release-please) properly will parse the compound commit message.
103+
1. Confirm the new/existing release PR is updated properly with the expected version number and changelog.

docs/sidebars.js

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -142,7 +142,7 @@ module.exports = {
142142
collapsed: true,
143143
items: [
144144
"development/contributing/clean-room",
145-
"development/contributing/commit-messages",
145+
"development/contributing/pull-requests",
146146
"development/contributing/documentation",
147147
],
148148
},

release-please-config.json

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
{
2+
"$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json",
3+
"bootstrap-sha": "2ded7919ebd63e0174bf5a412f6f01d6af0061c6",
4+
"release-type": "simple",
5+
"extra-files": ["app/VERSION"],
6+
"packages": {
7+
".": {}
8+
}
9+
}

0 commit comments

Comments
 (0)