build, GHA workflow: remove DEVELOCITY_ACCESS_KEY

[dsmiley]

I don't see any PR based CI workflow results in develocity, so these keys here aren't doing anything. And I think that's a good thing any way -- I don't want the test history to be potentially influenced by the rate of PRs and flaky PRs -- work-in-progress, after all.

Only docker-nightly.yml is an exception, which is cron based, not PR based, and I do see it in develocity. Not that I find it useful ;-) but it at least makes sense to me that it be there -- consistency with cron/Jenkins builds.

[janhoy]

Good catch, and nice with a comment to inform future committers on why the scheduled workflow has it.

Q: Will the PR builds try to push to develocity and fail / log error, or is there another flag to enable/disable develocity?

[dsmiley]

BTW our develocity config is here.
Not sure why the PR builds don't publish right now.

@clayburn I would ideally get your input on this... like do you think we maybe under-appreciate potential value of PR based build scans? I'd rather not even have to think of filtering them out when I'm on develocity.apache.org.

[clayburn]

PR builds could certainly have value. As you mention, it would need to be considered in dashboards, but cases where a PR is failing and needs investigation would be of interest. For example, you can do a scan comparison between your main branch and a PR to understand the scope of a dependency change.

In any event, PRs from forks can't see your secrets in order to publish, and we don't have a good solution yet, so there is not a good way to get these build scans.

[dsmiley]

I use Gradle dependency lockfiles to see how one branch/PR's dependencies differs from another.