1
1
# Preset: semver-workflow
2
2
3
- Add opinionated config and dependencies used by the Ecosystem team on Sanity to develop using
4
- semantic-release driven workflow on Github for Sanity v3 plugins.
3
+ ## Usage
4
+
5
+ ### Inject into existing package
6
+ ` npx @sanity/plugin-kit inject --preset-only --preset semver-workflow `
7
+
8
+ ### Use to init plugin
9
+ ` npx @sanity/plugin-kit init --preset semver-workflow <new-plugin-name> `
10
+
11
+ ## What does it do?
12
+
13
+ Adds opinionated config and dependencies used by the Ecosystem team on Sanity, to develop using
14
+ semantic-release driven workflow on Github.
15
+
16
+ ![ Github workflow] ( assets/semver-workflow-example.png )
17
+
18
+ This preset:
19
+
20
+ - adds [ husky] ( https://github.com/typicode/husky ) for pre-commit hooks to ensure that:
21
+ - all commits follow [ conventional-commits] ( https://www.conventionalcommits.org/en/v1.0.0/#summary ) format
22
+ - all files in a commit pass eslint
23
+ - [ semantic-release] ( https://semantic-release.gitbook.io/semantic-release/ ) automation for npm publish
24
+ - automates Github releases
25
+ - updates package version based on conventional-commits
26
+ - updates CHANGELOG.md
27
+ - [ GitHub workflow] ( https://docs.github.com/en/actions/using-workflows ) (Action) that
28
+ - does continuous integration
29
+ - has publish-on-demand support which delegates to semantic-release
30
+ - updates README.md with some standard texts, if missing
31
+
32
+ Keep in mind that this setup is tailored to the needs of the Ecosystem team at Sanity.
33
+ Feel free to modify any and all files injected by the preset, or use it as a basis for creating your own workflow.
5
34
6
35
## Manual steps after inject
7
36
@@ -20,18 +49,18 @@ Some text could be redundant or unnecessary depending on context and search for
20
49
21
50
Move text around until it looks good. Remember to change any v2 usage examples.
22
51
23
- ### 3. Update ` .github/workflows/main.yml ` branches
52
+ ### 3. Check ` .github/workflows/main.yml ` branches
24
53
25
54
This differs from repo to repo, default is ` [main] `
26
55
27
- In a typical plugin repo with a v2 and v3 version, it will typically look like this:
56
+ In a plugin repo with a v2 and v3 version, it could look like this:
28
57
29
58
``` yml
30
59
# .github/workflows/main.yml
31
60
name : CI & Release
32
61
on :
33
62
push :
34
- branches : [main, v3 ]
63
+ branches : [main, studio-v2 ]
35
64
` ` `
36
65
37
66
### 4. Check secrets
@@ -44,7 +73,7 @@ Ensure that your repo or Github org has set the secrets used by the workflow.
44
73
Secrets can be set using `Settings -> Secrets -> Actions -> "New repository secret"`
45
74
on Github for a repository.
46
75
47
- # ## 5. Update .releaserc.json
76
+ # ## 5. Check .releaserc.json
48
77
49
78
This differs from repo to repo. Branches defaults to `"branches" : ["main"]`
50
79
@@ -53,12 +82,13 @@ In a typical plugin repo with a v2 and v3 version, it will typically look like t
53
82
` ` ` json
54
83
{
55
84
"extends": "@sanity/semantic-release-preset",
56
- "branches": ["main", {"name": "v3 ", "channel": "studio-v3 ", "prerelease ": "v3-studio "}]
85
+ "branches": ["main", {"name": "studio-v2 ", "channel": "studio-v2 ", "range ": "1.x.x "}]
57
86
}
58
87
` ` `
59
88
60
- This assumes that the v2 version lives on `main` and the v3 versions livs on `v3`.
61
- The v3 version will be a pre-release using `studio-v3` as npm tag, and `v3-studio` version suffix.
89
+ This assumes that the v2 version lives on `studio-v2` branch and the v3 version livs on `main`.
90
+ The v2 version will be constrained to a version range and use `studio-v2` as npm tag.
91
+ The v3 version will be release with `latest` npm tag.
62
92
63
93
# ## 6. Test workflow and remove `--dry-run`
64
94
@@ -69,6 +99,7 @@ workflow for the V3-branch and check "Release new version".
69
99
70
100
Inspect the workflow logs to see the version that will be used for the release.
71
101
If it is ok, remove the `--dry-run` flag from the workflow to perform a real release.
102
+
72
103
If the version is not what you expected, you might have to perform some
73
104
[troubleshooting](https://semantic-release.gitbook.io/semantic-release/support/troubleshooting).
74
105
@@ -82,11 +113,8 @@ Now run:
82
113
This will run semantic-release in dry-run mode (no git push or npm publish) and show everything that would
83
114
go into a release.
84
115
85
- # # What does it do?
86
-
87
- Adds opinionated config and dependencies used by the Ecosystem team on Sanity to develop using
88
- semantic-release driven workflow on Github.
116
+ # ### Note on "notable commits"
117
+ As configured, semantic-release will not consider commits starting with `docs:` or `chore:` as notable.
118
+ If you only have non-notable commits since the last release, semantic-release will not create a new version.
89
119
90
- - Adds husky and related files and dependencies to do pre-commit checks
91
- - Adds semantic-release and preset dependencies to automate npm & Github releases
92
- - Updates README.md with some standard texts
120
+ Therefore, chores or doc updates that should be considered notable should use `fix(chore):` or `fix(docs):` suffix instead.
0 commit comments