Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automate release #758

Open
RodrigoHamuy opened this issue Sep 23, 2024 · 4 comments
Open

Automate release #758

RodrigoHamuy opened this issue Sep 23, 2024 · 4 comments
Labels
enhancement New feature or request

Comments

@RodrigoHamuy
Copy link

Would there be any interest in automating the release process?

That way whenever something is merged to master, we know it is getting released right away.

Thanks!

@RodrigoHamuy RodrigoHamuy added the enhancement New feature or request label Sep 23, 2024
@gkjohnson
Copy link
Contributor

I haven't used something like this before so I'm interested in what's involved but in general I prefer to keep publishing a more deliberate task so things like complete testing can be done and major / minor / patch versions can be determined. Would it be possible to automatically publish a new release when a tag is added through the github UI? Eg if a tag with "v0.4.1" is created on the master branch then a release with the same version identifier will be published.

@RodrigoHamuy
Copy link
Author

RodrigoHamuy commented Sep 23, 2024

About testing

You can also add PR preview using Vercel, so you can test things on PR rather than on merging to master.

It has a free tier and a Pro tier available for open source projects, so this should be available at no cost.

Even then, if things are released and bugs are noticed later, we can always just do another patch release with the fix.

About automated release

There are a few ways to do it, they all will take care of pushing to NPM, to Github Release and add git tags.

I am familiar with these two options, but there are others:

Option A

Using semantic-release, like they do it at DREI for example.

Option B

Using changesets like they do it at emotion.

I personally like Option B more because:

  • It doesn't release automatically, but rather generates automatically a release PR than once you decide to merge will kick the release.
  • I like to write the changes in a .md file that later are deleted and added to the CHANGELOG.md automatically rather than having to write changes in git comments.

@gkjohnson
Copy link
Contributor

The second "changesets" option definitely sounds better to me - it's still not clear to me how a release PR is initiated, though. Is this still something I have to pull and run locally to publish a release? Or can this all happen through the Gihub UI? If so and this is easy to set up I'm willing to give it a try to see how it works if you'd like to make a PR to start it out.

You can also add PR preview using Vercel, so you can test things on PR rather than on merging to master.

This would be nice to have, as well - and probably something three.js could benefit from, too. Are there any online writeups on this?

@RodrigoHamuy
Copy link
Author

RodrigoHamuy commented Sep 29, 2024

@gkjohnson added this PR which contains all the code needed to have changesets working :)

#764

Only thing left are adding the Changesets Bot and NPM_TOKEN secret as detailed in the PR description.

About using Vercel for PR previews, here is the tutorial, I believe there is no code required, everything can be set directly in the Vercel portal: https://vercel.com/docs/deployments/preview-deployments

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants