feat: next release from main branch is 2.67.0 #4108
Conversation
Summary of ChangesHello @blakeli0, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request prepares the repository for upcoming releases by setting up the necessary automation and safeguards for a new Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request configures a new release branch 2.66.x and prepares for the next main release. My review identifies a couple of areas for improvement. In the release-please.yml file, the new branch configuration contains redundant settings that are inherited from the top-level configuration. More importantly, it specifies primaryBranch: main, which is incorrect for a backport branch and should be removed. In sync-repo-settings.yaml, there's an inconsistency in the naming of required status checks which could be a typo. I've provided suggestions to address these points.
| - releaseType: java-backport | ||
| bumpMinorPreMajor: true | ||
| handleGHRelease: true | ||
| primaryBranch: main | ||
| manifest: true | ||
| extraFiles: | ||
| - WORKSPACE | ||
| - .cloudbuild/graalvm/cloudbuild.yaml | ||
| - .cloudbuild/graalvm/cloudbuild-test-a.yaml | ||
| - .cloudbuild/graalvm/cloudbuild-test-b.yaml | ||
| - .cloudbuild/graalvm/cloudbuild-test-c.yaml | ||
| - >- | ||
| .cloudbuild/library_generation/cloudbuild-library-generation-release.yaml | ||
| - >- | ||
| hermetic_build/library_generation/owlbot/templates/java_library/.kokoro/presubmit/graalvm-native-a.cfg | ||
| - >- | ||
| hermetic_build/library_generation/owlbot/templates/java_library/.kokoro/presubmit/graalvm-native-b.cfg | ||
| - >- | ||
| hermetic_build/library_generation/owlbot/templates/java_library/.kokoro/presubmit/graalvm-native-c.cfg | ||
| - generation_config.yaml | ||
| branch: 2.66.x |
There was a problem hiding this comment.
The configuration for the 2.66.x branch duplicates several settings from the top-level configuration (handleGHRelease, primaryBranch, manifest, and extraFiles). Branch-specific configurations in release-please inherit from the top-level settings, so this duplication is unnecessary and makes the file harder to maintain.
More critically, specifying primaryBranch: main for a backport branch is incorrect. It will cause release-please to look for commits on main to create a release for the 2.66.x branch, which is not the intended behavior for backports. Removing this key will make release-please correctly track commits on the 2.66.x branch itself.
I suggest removing the redundant keys to simplify the configuration and ensure correct behavior.
- releaseType: java-backport
bumpMinorPreMajor: true
branch: 2.66.x| - build(8) except for gapic-generator-java | ||
| - build(8) for gapic-generator-java |
There was a problem hiding this comment.
There's an inconsistency in the spacing for the build status check names. Other checks in this file, like build (11) and showcase (17), have a space before the parenthesis. The build(8) checks do not. While this might be intentional if the job names are exact, it's more likely a typo that could prevent these required status checks from being correctly enforced. For consistency and to avoid potential issues, I recommend adding a space.
- build (8) except for gapic-generator-java
- build (8) for gapic-generator-java
|
|
1 participant
enable releases