lorenzodejong / next-sanity-image

Utility for using responsive images hosted on the Sanity.io CDN with the Next.js image component.
MIT License
149 stars 20 forks source link

refactor(tooling): add sanity ecosystem automation #55

Closed stipsan closed 1 year ago

stipsan commented 1 year ago

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:

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.md

Semantic 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 with auth-only 2FA and add it to the repository secrets. And your npm package settings should set Publishing access to Require two-factor authentication or an automation or granular access token:

image

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 or feat: 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#options

Please 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:

image

As our preset will attempt to push a commit right after release that bumps the version in your package.json, adds another entry to the CHANGELOG.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 πŸ™‡

lorenzodejong commented 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!

stipsan commented 1 year ago

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!: :)

lorenzodejong commented 1 year ago

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!

github-actions[bot] commented 1 year ago

:tada: This PR is included in version 6.1.0 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

lorenzodejong commented 1 year ago

@stipsan wanted to let you know that we just ran the first release and it worked flawlessly! Thanks again for the effort πŸš€

stipsan commented 1 year ago

@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!! πŸŽ‰