-
-
Notifications
You must be signed in to change notification settings - Fork 903
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
Conversation
7a778bb
to
12e87c3
Compare
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? |
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 |
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. |
This can be closed here right? Got merged and shipped in v10.0.0 as I see in the changelog. |
@Shooteger: No, this about improving the release process in general, not about pushing out a specific release. |
@ctavan @pmccarren FWIW, the |
cc4c056
to
54c2219
Compare
9588d95
to
8a2d0d1
Compare
'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 |
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.