Skip to content

chore: restore nightly protobuf compatibility check - #13884

Merged
whowes merged 1 commit into
mainfrom
whowes/restore-proto-compat-check
Aug 6, 2026
Merged

chore: restore nightly protobuf compatibility check#13884
whowes merged 1 commit into
mainfrom
whowes/restore-proto-compat-check

Conversation

@whowes

@whowes whowes commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

Part of Issue #13867

  • restore/adapt previous GitHub Action config (see diff against last revision before deletion)
  • adjust logic and nomenclature for using modules of the monorepo v. previous separate repos
  • add showcase testing
  • address findings from Zizmor static analysis and Gemini code review

Passing manual workflow run: https://github.com/googleapis/google-cloud-java/actions/runs/31056514739

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request refactors the nightly downstream Protobuf compatibility scripts to test local monorepo submodules directly instead of cloning them from GitHub, removing the special-casing for the google-cloud-java repository. Feedback on these changes recommends using standard CLI commands to retrieve tool versions rather than manually parsing versions.txt, redirecting error messages to standard error (>&2), and appending || exit 1 to pushd commands to ensure the scripts terminate safely if directory changes fail.

Comment thread sdk-platform-java/.kokoro/nightly/downstream-protobuf-binary-compatibility.sh Outdated
Comment thread sdk-platform-java/.kokoro/nightly/downstream-protobuf-binary-compatibility.sh Outdated
Comment thread sdk-platform-java/.kokoro/nightly/downstream-protobuf-binary-compatibility.sh Outdated
Comment thread sdk-platform-java/.kokoro/nightly/downstream-protobuf-source-compatibility.sh Outdated
Comment thread sdk-platform-java/.kokoro/nightly/downstream-protobuf-source-compatibility.sh Outdated
@whowes
whowes force-pushed the whowes/restore-proto-compat-check branch 22 times, most recently from d8b7a8e to 24ef975 Compare July 25, 2026 01:54
@whowes

whowes commented Jul 26, 2026

Copy link
Copy Markdown
Contributor Author

/gemini review

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request updates the Kokoro nightly downstream compatibility scripts to test local monorepo submodules instead of cloning external repositories. It also adds KMS dependencies to the installation list, excludes StorageITRunnerTest from storage tests, and configures test options for Java 8 compatibility. Feedback on the changes suggests improving Bash script efficiency and robustness, specifically by using native parameter expansion instead of cut, avoiding useless use of cat with grep, and using Bash arrays instead of unquoted string variables to prevent word splitting issues.

@whowes
whowes force-pushed the whowes/restore-proto-compat-check branch 3 times, most recently from 72be2a8 to 41ffb2b Compare July 27, 2026 19:41
@whowes
whowes marked this pull request as ready for review July 27, 2026 22:45
@whowes
whowes requested a review from a team as a code owner July 27, 2026 22:45
@whowes
whowes requested review from a team as code owners July 27, 2026 22:45
@whowes
whowes requested a review from lqiu96 July 27, 2026 22:45
@whowes
whowes force-pushed the whowes/restore-proto-compat-check branch from 41ffb2b to b32cefc Compare August 4, 2026 18:35
@whowes whowes added the kokoro:force-run Add this label to force Kokoro to re-run the tests. label Aug 4, 2026
@yoshi-kokoro yoshi-kokoro removed the kokoro:force-run Add this label to force Kokoro to re-run the tests. label Aug 4, 2026
- uses: actions/setup-java@c1e323688fd81a25caa38c78aa6df2d33d3e20d9 # v4
with:
java-version: 11
distribution: temurin

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe we can add the cache: config here to see if this can resolve the deps (I don't think the deps will be changing too much).

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

might be worth confirm with the Storage SMEs @ShreyasSinha if this is fine

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dug into this more and it looks like the offending test just needed some GCP project name set to pass (not required to actually be a valid project), so I provided one and stopped excluding it here.

- java-translate
# Default Protobuf-Java versions to use are specified here. Without this, the nightly workflow won't know
# which values to use and would resolve to ''.
protobuf-version: ${{ fromJSON(format('[{0}]', inputs.protobuf_runtime_versions || '"4.35.1"')) }}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

qq, do we want to keep this aligned with the version of protobuf in pom-parent or with the latest protobuf-java available? CC: @blakeli0 if you have any thoughts.

I think the original intention was with the version of pom-parent, but that was when we were doing the migration. Now that 3.x and 4.x are mostly compatible we may not need that

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's good context that this was originally intended to test against pom-parent's version. I switched to test against that version instead by default for now, but it might be worth discussing further whether we want to switch to testing against the latest version (or doing both, which is supported by passing in multiple versions via the inputs).

@lqiu96 lqiu96 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm. added some small comments, but the changes generally looks good on my end and the manual workflow passes. thanks for the fix!

@whowes
whowes force-pushed the whowes/restore-proto-compat-check branch 3 times, most recently from bc99190 to 695a897 Compare August 5, 2026 23:11
@whowes
whowes force-pushed the whowes/restore-proto-compat-check branch from 695a897 to 5e40fdc Compare August 5, 2026 23:28
@sonarqubecloud

sonarqubecloud Bot commented Aug 5, 2026

Copy link
Copy Markdown

@sonarqubecloud

sonarqubecloud Bot commented Aug 5, 2026

Copy link
Copy Markdown

@whowes
whowes merged commit 6487543 into main Aug 6, 2026
267 of 270 checks passed
@whowes
whowes deleted the whowes/restore-proto-compat-check branch August 6, 2026 01:07
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.

3 participants