Fetching Build Scan data for all builds dumps 404 error pages in logs

[SimonMarquis]

When using the default Gradle Scans endpoint, API calls are not allowed.
Leading to 404 errors when the scripts are trying to fetch all the build scan data.
Here is an example: https://github.com/SimonMarquis/SealedObjectInstances/actions/runs/12433888640/job/34716406872?pr=313#step:5:452

Unfortunately, the whole HTML page is then dumped to the logs.
Is this on purpose? If not, can we prevent to dump this useless content to the logs?

Thanks

[erichaagdev]

Hi, @SimonMarquis. Thanks for taking the time to file this issue.

The Develocity Build Validation Scripts are not intended to be used with https://scans.gradle.com. We will discuss internally to see if we can make this experience better.

[erichaagdev]

Hi @SimonMarquis. As you already pointed out, API calls are not allowed to scans.gradle.com, and we don't have any plans to change this.

The typical use case for running these in CI is to automatically catch build caching regressions by using the failIfNotFullyCacheable option. This option only works with access to the Develocity API which we use to determine task outcomes. Therefore, even if we improved the experience of using the scripts with scans.gradle.com, we will never be able to make failIfNotFullyCacheable work with it and you would need to manually check the resulting build scans yourself.

Could you help me understand your use case for running the Develocity Build Validation Scripts? Is it to catch build caching regressions?

[SimonMarquis]

Could you help me understand your use case for running the Develocity Build Validation Scripts? Is it to catch build caching regressions?

Yes, exactly.
I fully understand the limitations of the public scans endpoint and that it is not meant to be targeted through API calls.
The only issue I had was that I was trying to debug something, and I was presented the entire HTML dump of the webpage in the logs. And this is probably not useful to anyone (a simple error message with the response message and error code would suffice) and makes the debugging experience slightly worse than it needs to be.

If this is not planned or if you find this would need to support too many edge cases, then I'll be fine closing this issue.