tests: Use fixed copyright year in tests.

[blakeli0]

The generator use the current year to generate copyright headers, so there are multiple tests failing when a new year comes. The general fix is to introduce an environment variable TEST_CURRENT_YEAR so that we can override it in tests. See below for the exact fix for each scenario:

• Java generator golden unit tests
  • Override it with Maven.
• Java generator golden integration tests
  • Updated the golden files. These tests are generated from Bazel rules. Bazel builds are pretty hermetic and I couldn't find a way to override the environment variable. This is because the Bazel rule java_gapic_library calls the generator through proto_custom_library which does not pass any environment variables.
• Python hermetic build scripts unit tests.
  • Override it with mocks. This requires a small refactoring in java.py.
• Hermetic build scripts integration tests.
  • Changed these tests to non-required for now. These tests use a hardcoded generator version that does not recognize the environment variable. Once the generator is released, we can update the generator version and override the environment variable in CloudBuild yamls.
• SpringCodeGen unit tests.
  • Once the generator is released, we can override the same environment variable with Maven in spring-cloud-gcp.

Separately, updated zlib version in Bazel build because there is a known incompatibility between old zlib library and the latest macOS version.

fixes: #3547

[gemini-code-assist]

Summary of Changes

Hello @blakeli0, I'm Gemini Code Assist¹! 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 enhances the robustness of the test suite by introducing a configurable copyright year for generated code. By allowing the copyright year to be set via an environment variable, particularly for tests, it ensures that test outcomes remain consistent and independent of the actual calendar year, thereby preventing potential test failures caused by year transitions.

Highlights

• Test Stability Improvement: Introduced a mechanism to fix the copyright year used in generated code during testing, which prevents tests from failing due to year changes.
• Configurable Copyright Year: The copyright year can now be overridden for testing purposes using the test_current_year environment variable.
• Maven Surefire Plugin Configuration: The pom.xml was updated to set the test_current_year environment variable to 2025 specifically for test execution.
• Dynamic Year Retrieval: A new getCurrentYear() helper method was added to CommentComposer.java to dynamically determine the copyright year, prioritizing the environment variable over the system's current year.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

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

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a mechanism to use a fixed copyright year for tests by using an environment variable. The changes in pom.xml set this environment variable for the test execution, and CommentComposer.java is updated to read this variable. This is a good approach for making tests deterministic.

I've added one comment with a suggestion to refactor the new getCurrentYear method to improve maintainability by extracting the magic string into a constant and to use the modern java.time API instead of Calendar.

[lqiu96]

qq, would this override the value of an env var I set locally on my computer? Do you know which one has precendence?

If this takes precedence, maybe we can set this as a maven property so that we can configure this (if we need to ever test locally) with something like -DoverrideYear=YEAR

[blakeli0]

Thanks for the suggestion! I made it a Maven property since it's generally a better practice. I tested that this override does take precedence.

[zhumin8]

LTGM. I'd be great if you could add a bit of documentation:

• Document this new env variable perhaps in https://github.com/googleapis/sdk-platform-java/blob/main/hermetic_build/README.md
• Make a note that env var does not apply to "Java generator golden integration tests" as you explained in the description, so this nuance is not lost.

[blakeli0]

LTGM. I'd be great if you could add a bit of documentation:

• Document this new env variable perhaps in https://github.com/googleapis/sdk-platform-java/blob/main/hermetic_build/README.md
• Make a note that env var does not apply to "Java generator golden integration tests" as you explained in the description, so this nuance is not lost.

I added more comments to CommentComposer, including nuances of the golden integration tests as well.
I don't think we should document this in README though because this is more like a test only thing to make developers' life easier, it's actually better if developers do not notice this at all.

[sonarqubecloud]

Quality Gate failed for 'gapic-generator-java-root'

Failed conditions
75.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud

[sonarqubecloud]

Quality Gate passed for 'java_showcase_integration_tests'

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud