Merge main -> release/1.7 #3369
Conversation
#3361) It seems that the changelog got merged for `1.7.0`, but the `VERSION_NEXT_FEATURE` got added to the docs instead of `1.7.0`. This is fixing that so that we can merge/cherry-pick again to the release branch.
The GitHub App is deprecated, so switch to the more modern workflow. This will also allow us to eventually use attestations. Along the way... * Split up the release workflow into some different sub-jobs * Run PyPI upload last, as its the most irrevocable step of the process.
…3355) The create_archive_and_notes.sh script is incorrectly detecting the version markers in the tool meant to rewrite them. To fix, ignore those files.
…nt (#3365) BCR recently changed how it extracts archives in its presubmits: instead of extracting the whole archive, only the specified portion (`gazelle/` in this case) is extracted. This broke the gazelle tests because they reference files above the gazelle directory. To fix, move the module it runs as a test under the gazelle directory. Because the test module also refers to rules_python, which is above the gazelle directory, the bcr presubmit has disable that override using `--override_module`. This means, going forward, the gazelle module, when bcr tests it, will use the version in the MODULE file (rather than the vendored copy). Fixes #3364
My original change to use the bazel-contrib BCR publishing workflow was horribly broken. This fixes a variety of issues. * Fix the workflow call secrets variable name * Allow getting the BCR publishing token from the workflow arg (the release workflow calls it) * Fix the overall syntax of the workflows. It was just entirely invalid in several regards. * Fix the yaml -> yml file name reference. NGL, it took me longer than I'd like to admit to see that, eh. Along the way, some cleanups and improvements * Allow specifying a particular tag to release, while using workflow state from a different commit. This allows us to make fixes on main, and then use it to manually re-trigger a tag to be released. * Add descriptions for workflow inputs * Allow bcr token to be passed to release. This will allow e.g. automatically scheduled releases. * Quote shell variables because its good practice.
Summary of ChangesHello @rickeylev, 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 primarily focuses on a structural refactoring by relocating the Highlights
Ignored Files
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 merges changes from main into the release/1.7 branch. The changes primarily consist of moving an example from examples/ to gazelle/examples/, updating configuration files (.bazelci/presubmit.yml, .bazelrc, .bazelignore, MODULE.bazel) to reflect this move, and bumping version numbers in documentation and dependency definitions for the 1.7 release. My review includes a few suggestions to improve maintainability by removing redundant configuration and consolidating flags in .bazelrc files.
| gazelle/examples/bzlmod_build_file_generation/bazel-bin | ||
| gazelle/examples/bzlmod_build_file_generation/bazel-bzlmod_build_file_generation | ||
| gazelle/examples/bzlmod_build_file_generation/bazel-out | ||
| gazelle/examples/bzlmod_build_file_generation/bazel-testlog |
There was a problem hiding this comment.
The newly added gazelle/.bazelignore file already handles ignoring these Bazel-generated directories within the gazelle/examples/bzlmod_build_file_generation path. These entries in the root .bazelignore are therefore redundant and can be removed to avoid duplication and simplify maintenance.
| common --deleted_packages=gazelle/examples/bzlmod_build_file_generation | ||
| common --deleted_packages=gazelle/examples/bzlmod_build_file_generation/runfiles |
There was a problem hiding this comment.
For better readability and consistency with other parts of this file (like the query --deleted_packages on line 9), you can combine these two deleted_packages flags into a single line with comma-separated paths.
common --deleted_packages=gazelle/examples/bzlmod_build_file_generation,gazelle/examples/bzlmod_build_file_generation/runfiles
|
For fun, I tried using a PR to update the 1.7 branch with main. Two notes:
|
|
Huh. I did the merge locally and it seems to have resolved this PR? Weird... |
Merges main into release/1.7