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

Draft
wants to merge 7 commits into
base: main
Choose a base branch
from

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.

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.

None yet

3 participants