Closed stipsan closed 1 year ago
This is completely awesome! Thanks for the effort and all the clear documentation you provided.
I think all the code is fairly clear, however i was wondering what would happen during the first time i release. How can i determine a follow-up of the existing version number, will the commit-analyzer pick up the changes as a major version change initially?
I'll make sure to follow the steps you've provided and also change to pnpm, i'm already using that for all other projects so i like the change!
I think all the code is fairly clear, however i was wondering what would happen during the first time i release. How can i determine a follow-up of the existing version number, will the commit-analyzer pick up the changes as a major version change initially?
The first time it runs it'll try and look at the package on npm as well as the git tags to determine what the current version is. I see that the current version is 6.0.0
but you don't have a v6.0.0
tag. semantic-release uses v
prefixes for its tags. Create a v6.0.0
tag and it'll only look at commits since that tag when determining a new release.
Then, to make a new release, you use commits like fix: removed bug
, the fix
prefixes makes it a patch increment: 6.0.1
. For 6.1.0
you'll need the feat:
prefix. To bump major you can use either feat!:
or fix!:
:)
Great! I made sure to create a v6.0.0
tag to make sure the latest version is picked up correctly. Will get this PR integrated and try it out with the next release.
Thanks for the effort, and very nice we could get a collaboration going. Very cool to hear that this is used on the Sanity website, so i'd be happy to hear any feedback when using this library!
:tada: This PR is included in version 6.1.0 :tada:
The release is available on:
Your semantic-release bot :package::rocket:
@stipsan wanted to let you know that we just ran the first release and it worked flawlessly! Thanks again for the effort π
@stipsan wanted to let you know that we just ran the first release and it worked flawlessly! Thanks again for the effort π
Great to hear!! π
Hi π
As promised in https://github.com/sanity-io/next-sanity/issues/5#issuecomment-1485340133 here's a PR with the typical automation we use in our own libraries like
next-sanity
and@sanity/client
πI'll keep the PR description brief, but please feel free to ask questions in diff comments and I'll do my best to fill you in on the deets π
TL;DR
The automation is for:
CHANGELOG.md
file with semantic-release.peerDependencies
let your consumers use the latest and notifies you if any.github/workflows/*.yml
files have shared actions that can be updated.main
.Next steps a maintainer with admin powers should do
Renovatebot
For Renovate to be enabled you need to install the app. We recommend enabling it on one repository at a time since it will create onboarding PRs on repos without a
renovate.json
file by default which can blast your email inbox and be really noisy. Once enabled you should see it create a GitHub issue like this: https://github.com/sanity-io/next-sanity/issues/58 More information on the preset itself: https://github.com/sanity-io/renovate-presets/blob/main/ecosystem/README.mdSemantic Release
There's detailed information on our preset here: https://github.com/sanity-io/semantic-release-preset Most importantly you'll need to create an
NPM_PUBLISH_TOKEN
withauth-only
2FA and add it to the repository secrets. And your npm package settings should setPublishing access
toRequire two-factor authentication or an automation or granular access token
:I noticed you're using a different git commit convention than ours. If you decide to adopt conventional commits then the next time you push a commit prefixed with
fix: the bug is gone
orfeat: images pop even more
then you can make a new release using this flow:https://user-images.githubusercontent.com/81981/230077498-337e0cbf-9470-48e9-b7c9-08658a16db85.mov
If you wish to stick to your current convention then, as semantic release presets don't really support merging presets, it's best to replace the
.releaserc.json
file in this PR with a new.releaserc.cjs
that have the contents of our preset: https://github.com/sanity-io/semantic-release-preset/blob/main/index.js The commit preset used is defined at the top. Here's a list over available presets: https://github.com/semantic-release/commit-analyzer#optionsPlease note that our Release preset currently requires the ability to directly push commits to
main
Specifically this means that all GitHub branch protection rules that require a PR to be made before you can push to
main
, can't be used:As our preset will attempt to push a commit right after release that bumps the
version
in yourpackage.json
, adds another entry to theCHANGELOG.md
(or creates the file if it doesn't already exist), and pushes it right away.We're working on an updated preset that is compatible with PR based branch protection rules and will let you know when that's available π