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

build: Enable release-please workflow for release, fixes #636 #725

Merged
merged 20 commits into from
Oct 27, 2024

Conversation

broofa
Copy link
Member

@broofa broofa commented Aug 24, 2023

See https://github.com/googleapis/release-please.

tl;dr: New commits will trigger the creation of a "release PR". Merging the release PR will automatically create a new release.

I'm not super-familiar with this, so will probably be flailing around a bit in this PR as I figure out what's needed. And, alas, knowing for sure that it's working requires actually publishing releases.

@broofa broofa marked this pull request as draft August 24, 2023 17:11
@broofa broofa force-pushed the release-please branch 2 times, most recently from 7a778bb to 12e87c3 Compare August 24, 2023 17:53
@ctavan
Copy link
Member

ctavan commented Aug 24, 2023

Awesome!

I think for this to be maximally useful we need to somehow enforce that the commit messages of our squash commits that go into the main branch follow the conventional commit format.

I think we do have a presubmit that checks this when committing locally, but this is not run upon squash merging a PR.

Any idea how we could enforce properly formatted messages for these squash merges?

@broofa
Copy link
Member Author

broofa commented Aug 24, 2023

I think for this to be maximally useful we need to somehow enforce that the commit messages of our squash commits that go into the main branch follow the conventional commit format.

I don't have a good solution to that at the moment. ... but that's also a separate issue from this PR, right?

FWIW, I'm bogged down at the moment on the lack of support for prerelease versions in release-please. I'd really like to get this setup for the rfc4122bis branch so we can publish to NPM using "9.0.0-bis.#"-style versions, but blocked by this issue. (I'm not well-versed in how release-please works, though, so there may be a workaround...?)

@ctavan
Copy link
Member

ctavan commented Aug 24, 2023

I think for this to be maximally useful we need to somehow enforce that the commit messages of our squash commits that go into the main branch follow the conventional commit format.

I don't have a good solution to that at the moment. ... but that's also a separate issue from this PR, right?

Correct, it‘s an independent issue. However I‘m wondering if we should fix the conventional-commit enforcement first? I think release automation can only reliably pick the right major/minor/patch version to increment if the commit messages obey the conventional commit rules. Otherwise we may end up with release-please creating minor bumps for breaking changes. OTOH it only generates a pull request so we still have human supervision. Given that, I think the order in which we do those two things actually doesn’t matter.

@broofa broofa mentioned this pull request Jun 3, 2024
2 tasks
@Shooteger
Copy link

This can be closed here right? Got merged and shipped in v10.0.0 as I see in the changelog.

@broofa
Copy link
Member Author

broofa commented Jun 10, 2024

@Shooteger: No, this about improving the release process in general, not about pushing out a specific release.

@broofa
Copy link
Member Author

broofa commented Jun 18, 2024

@ctavan @pmccarren FWIW, the standard-version (that we depend on) was deprecated last year and now recommends using release-please instead: https://github.com/conventional-changelog/standard-version

@broofa broofa marked this pull request as ready for review October 27, 2024 02:01
@broofa
Copy link
Member Author

broofa commented Oct 27, 2024

'Not really sure how well this is going to work but this PR is long in the tooth and the way release-please works makes it difficult to properly test on a branch. So I'm merging and will work the kinks out as part of rolling v11.

@broofa broofa merged commit 5e9a857 into main Oct 27, 2024
14 checks passed
@broofa broofa deleted the release-please branch October 27, 2024 02:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants