Repository navigation
Add PipelineOptions changes for merging ValidatesRunner tests. - #40437
Conversation
|
Checks are failing. Will not request review until checks are succeeding. If you'd like to override that behavior, comment |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #40437 +/- ##
============================================
- Coverage 59.04% 58.74% -0.30%
+ Complexity 15624 13911 -1713
============================================
Files 2797 2583 -214
Lines 280750 271479 -9271
Branches 12488 11240 -1248
============================================
- Hits 165764 159491 -6273
+ Misses 108540 105990 -2550
+ Partials 6446 5998 -448
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Assigning reviewers: R: @chamikaramj for label java. This pull request likely touches a core component ("core" label). Please review with scrutiny. Note: If you would like to opt out of this review, comment Available commands:
The PR bot will only process comments in the main thread (not review comments). |
|
@kennknowles friendly ping |
When merging ValidatesRunner tests, we need to ensure that pipelines with differing PipelineOptions (including and PIpelineOptions subclass) are not merged together. This simple approach of just serializing the options (MAPPER.valueToTree(options).get("options")), however that contains every bound value. As a result, two options objects configured identically can serialize differently depending purely on which getters happened to be called on each — e.g. View.asList() and Reshuffle read updateCompatibilityVersion during construction, and GcsFileSystem reads gcsPerformanceMetrics, so a pipeline that uses them "has" those keys and one that doesn't, doesn't. In these cases the getters simply return the default values, so the PipelineOptions are logically the same.
There is a BoundValue.isDefault bit (private) that one might try to use to solve this problem, by excluding default-values from the comparison. However testing often roundtrips options through JSON, after which this isDefault bit is lost.
This PR introduces PipelineOptionsFactory.explicitlySetProperties(PipelineOptions) which returns the names of properties that have been explicitly set. In order to maintain things across roundtrips, we introduce a new field in the serialized JSON to track any fields that have lazily-bound defaults. This is currently not enabled in production pipelines - it's only enabled by TestPipeline.java.