You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
### Motivation
We currently lack awareness on how old builds are during fuzz task. This
PR implements that, by making the assumption that the Last Update Time
metadata field in GCS is a good proxy for build age. [Documentation
reference](https://cloud.google.com/storage/docs/json_api/v1/objects#resource)
### Approach
Symbolized and custom builds do not matter, thus all builds of interest
will be fetched from ```build_manager.setup_regular_build```. Logic for
collecting all bucket paths and the latest revision was refactored, so
that ```setup_regular_build``` can also figure out the latest revision
for a given build and conditionally emit the proposed metric.
### Testing strategy
!Todo: test this for fuzz, analyze, progression
Locally ran tasks, with instructions from #4343 and #4345 , and verified
the _emmit_build_age_metric function gets invoked and produces sane
output.
Commands used:
```
fuzz libFuzzer libfuzzer_asan_log4j2
```

```
progression 4992158360403968 libfuzzer_asan_qt
```

```
analyze 4992158360403968 libfuzzer_asan_qt (disclaimer: build revision was overriden mid flight to force a trunk build, since this testcase was already tied to a crash revision)
```

Part of #4271
0 commit comments