Skip to content
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

chore: generate poms with grpc dependencies as test scoped #3072

Merged
merged 9 commits into from
Aug 31, 2024

Conversation

diegomarquezp
Copy link
Contributor

@diegomarquezp diegomarquezp commented Jul 26, 2024

Fixes googleapis/google-cloud-java#10037

Overview

This will modify the behavior of library generation at the postprocessing stage. The main change is that generated cloud poms (i.e. google-cloud-${service}/pom.xml) will now have the dependencies proto-google-common-protos and grpc-google-iam-v1 declared as <scope>test</scope> if the libraries belong to a monorepo.

Integration test

It will be failing until we update the test branch. Once this approach is validated, I will proceed with updating the branch.

Approach

For new libraries

Via template in owlbot/teplates/poms/cloud_pom.xml.j2. New libraries will have these two dependencies declared as test scope if they are part of a monorepo.

For existing libraries

The script fix_poms.py will now modify the existing poms by setting the two dependencies as test-scoped, only if they are part of a monorepo.

Confirmation that it works

@product-auto-label product-auto-label bot added the size: m Pull request size is medium. label Jul 26, 2024
@diegomarquezp diegomarquezp requested a review from blakeli0 July 29, 2024 14:08
@@ -39,10 +39,12 @@
<groupId>com.google.protobuf</groupId>
<artifactId>protobuf-java</artifactId>
</dependency>
{%- if repo in ['java-storage', 'java-spanner', 'java-dataproc'] %}
<dependency>
<groupId>com.google.api.grpc</groupId>
<artifactId>proto-google-common-protos</artifactId>
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think what was asked is grpc-google-common-protos, not proto-google-common-protos.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

True, my bad! I corrected it.

@@ -72,16 +74,30 @@
<groupId>com.google.api.grpc</groupId>
<artifactId>proto-google-iam-v1</artifactId>
</dependency>
{%- if repo in ['java-storage', 'java-spanner', 'java-dataproc'] %}
Copy link
Collaborator

Choose a reason for hiding this comment

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

I know I said hardcoding is not too bad if there is only a few, but I noticed that we already have excluded_dependencies that is used in pom generation, how much effort would it be to introduce a test_dependencies as well?

Copy link
Contributor Author

@diegomarquezp diegomarquezp Jul 30, 2024

Choose a reason for hiding this comment

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

excluded_dependencies prevents items from the existing_modules list to be added into the final required_dependencies list. required_dependencies is then split into proto_modules and grpc_modules and passed into update_cloud_bom.

Each gRPC module (from required_dependencies -> grpc_modules) passed into update_cloud_bom is added as a <scope>test</scope> dependency if not already existing. It does nothing if it's already existing.

Excluding the dependencies via .repo-metadata.json would not cause the dependencies to be removed since this logic is only to prevent new dependencies from being added to the pom.

Edit: I misunderstood your point. I'll address it in the next comment of this thread.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Adding a test_dependencies config key in repo_metadata would make sense. We can intersect the contents of test_dependencies and required_dependencies to convert existing poms' dependencies to test-scoped.

I think the effort is small when it comes to fix_poms.py (the hardcoded array is now obtained from repo-metadata).

The other part would be to have a mini-script to create a PR for all libraries in google-cloud-java except java-dataproc.

I guess we can keep adding entries to .repo-metadata since we already have java-postprocessing-specific ones.

Conclusion: small effort.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We decided to rely on the monorepo variable instead, since the only case where it would not compile is for java-dataproc, but it was because it needed the transitive dependency proto-google-iam-v1, so the correct approach is to also set its targeted dependencies as test-scoped and additionally include proto-google-iam-v1 (imported here).

Copy link
Collaborator

Choose a reason for hiding this comment

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

Can you please remind me when fix_poms.py is called? IIRC, both on new client library generation and as part of the post-processing?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, it's part of running our owlbot postprocessor

# write or restore pom.xml files
echo "Generating missing pom.xml..."
python3 "${scripts_root}/owlbot/src/fix_poms.py" "${versions_file}" "${is_monorepo}"
echo "...done"

# as of July 2024, we have two dependencies that should be declared as
# test-scoped: grpc-google-common-protos and grpc-google-iam-v1. Only in
# java-storage, java-spanner and java-dataproc we keep them as they are
TEST_SCOPED_DEPENDENCIES = ["grpc-google-common-protos", "grpc-google-iam-v1"]
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm not sure I understand why we need this part. Is the template change not enough?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The template is rendered only on new libraries, otherwise the function update_cloud_pom() is called.

if os.path.isfile(f"{artifact_id}/pom.xml"):
print("updating modules in cloud pom.xml")
if artifact_id not in excluded_poms_list:
update_cloud_pom(
f"{artifact_id}/pom.xml", proto_modules, grpc_modules, repo_metadata
)
elif artifact_id not in excluded_poms_list:
print("creating missing cloud pom.xml")
templates.render(
template_name="cloud_pom.xml.j2",

Copy link
Collaborator

Choose a reason for hiding this comment

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

This golden file tests the changes in fix_poms.py?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@blakeli0 yes, this is the unit test that deals with this golden:

resources_dir = os.path.join(script_dir, "..", "resources", "test-owlbot")
class FixPomsTest(unittest.TestCase):
def test_update_poms_group_id_does_not_start_with_google_correctly(self):
ad_manager_resource = os.path.join(resources_dir, "java-admanager")
versions_file = os.path.join(ad_manager_resource, "versions.txt")
os.chdir(ad_manager_resource)
sub_dirs = ["ad-manager", "ad-manager-bom", "proto-ad-manager-v1", "."]
for sub_dir in sub_dirs:
self.__copy__golden(ad_manager_resource, sub_dir)
main(versions_file, "true")
for sub_dir in sub_dirs:
self.assertFalse(compare_pom_in_subdir(ad_manager_resource, sub_dir))
for sub_dir in sub_dirs:
self.__remove_file_in_subdir(ad_manager_resource, sub_dir)

@@ -104,6 +109,9 @@ def update_cloud_pom(
if m.find("{http://maven.apache.org/POM/4.0.0}artifactId") is not None
]

if is_monorepo:
Copy link
Collaborator

Choose a reason for hiding this comment

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

I guess this is more like a one time thing to fix the existing poms? After that, this logic would be a no-op?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

With this change, if we ever declare this dep as compile-scoped in a monorepo library, then it will be turned back to test-scoped.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I see, to prevent accidental manual changes.

Copy link
Collaborator

@blakeli0 blakeli0 left a comment

Choose a reason for hiding this comment

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

LGTM.
Can you please update the description to reflect the recent changes before merging?
And update the dataproc module in google-cloud-java as a follow up?

@@ -104,6 +109,9 @@ def update_cloud_pom(
if m.find("{http://maven.apache.org/POM/4.0.0}artifactId") is not None
]

if is_monorepo:
Copy link
Collaborator

Choose a reason for hiding this comment

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

I see, to prevent accidental manual changes.

@diegomarquezp diegomarquezp added the automerge Merge the pull request once unit tests and other checks pass. label Aug 31, 2024
Copy link

Copy link

Quality Gate Passed 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 SonarCloud

@diegomarquezp diegomarquezp merged commit 0e784a2 into main Aug 31, 2024
34 checks passed
@diegomarquezp diegomarquezp deleted the conditional-pom-generation branch August 31, 2024 01:04
@gcf-merge-on-green gcf-merge-on-green bot removed the automerge Merge the pull request once unit tests and other checks pass. label Aug 31, 2024
ldetmer pushed a commit that referenced this pull request Sep 17, 2024
Fixes googleapis/google-cloud-java#10037 ☕ 

### Overview

This will modify the behavior of library generation at the
postprocessing stage. The main change is that generated _cloud_ poms
(i.e. `google-cloud-${service}/pom.xml`) will now have the dependencies
`proto-google-common-protos` and `grpc-google-iam-v1` declared as
`<scope>test</scope>` if the libraries belong to a monorepo.

### Integration test

It will be failing until we update the test branch. Once this approach
is validated, I will proceed with updating the branch.

### Approach
#### For new libraries
Via template in `owlbot/teplates/poms/cloud_pom.xml.j2`. New libraries
will have these two dependencies declared as test scope if they are part
of a monorepo.

#### For existing libraries
The script `fix_poms.py` will now modify the existing poms by setting
the two dependencies as test-scoped, only if they are part of a
monorepo.

### Confirmation that it works
* java-bigquerystorage: no effects since these dependencies are [not
found in the
pom](https://github.com/search?q=repo%3Agoogleapis%2Fjava-bigquerystorage%20path%3Agoogle-cloud-bigquerystorage%2Fpom.xml%20grpc-google&type=code)
* java-datastore: [no relevant
changes](https://github.com/googleapis/java-datastore/pull/1530/files)
since the dependencies are [not found in the
pom](https://github.com/googleapis/java-datastore/blob/main/google-cloud-datastore/pom.xml)
* java-firestore: [no relevant
changes](googleapis/java-firestore#1764) since
the one targeted dependency is [already declared as test
scoped](https://github.com/googleapis/java-firestore/blob/main/google-cloud-firestore/pom.xml#L160-L164)
* java-logging: [no relevant
changes](googleapis/java-logging#1660)] since
the dependencies are [not declared in the
pom](https://github.com/googleapis/java-logging/blob/main/google-cloud-logging/pom.xml)
* java-pubsub: no changes. Relevant dependency [already declared as test
scoped](https://github.com/googleapis/java-pubsub/blob/2b15b0a3f43c9ccef663fedf0398375f58fd9183/google-cloud-pubsub/pom.xml#L135-L139)
* java-pubsublite: [no relevant
changes](googleapis/java-pubsublite#1692) since
there are [no relevant dependencies declared in the
pom](https://github.com/googleapis/java-pubsublite/blob/main/google-cloud-pubsublite/pom.xml)
 * java-spanner: ignored - dependency kept as is
 * java-storage: ignored - kept as is
* **google-cloud-java: [91 poms
affected](https://github.com/googleapis/google-cloud-java/pull/11031/files)
by converting dependencies to test-scoped (PR only contains pom changes
for simplicity + outdated googleapis_committish)**
* We had a special situation with `java-dataproc` because it references
`google-iam-v1` via `grpc-google-iam-v1`. However this is incorrect
because what this library really needs is the proto classes. The fix for
this was to treat this library as any other library and add
`proto-google-iam-v1` as a dependency.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hermetic-build size: m Pull request size is medium.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Some dependencies in java-alloydb/google-cloud-alloydb module seem to have wrong dependency scopes.
2 participants