The interesting part of build-scans is to have those even for CI runs on
PRs - to get more insights into the build/CI run.
But with a GH secret, as required by ge.apache.org, you cannot have have
that, because then you would have to give all CI jobs access to secrets
--> pwn [1]. That's the reason to at least have those scans on Gradle's
infra, which doesn't require authentication.
[1]
https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/
PS: Remote caching is a different topic. IIRC the Iceberg build has some
customizations that render Gradle's caching less efficient as it could be.
On 25.11.24 15:10, Jean-Baptiste Onofré wrote:
We are using it in Apache Beam via this configuration:
develocity {
server = "https://ge.apache.org";
buildScan {
uploadInBackground = !isCi
publishing.onlyIf { it.isAuthenticated }
obfuscation {
ipAddresses { addresses -> addresses.map { "0.0.0.0" } }
}
}
}
and using the "com.gradle.develocity" plugin.
It's documented here:
https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=Project+Onboarding+Instructions+for+Develocity
For GitHub Actions builds in the Apache GitHub organization, an access
token is stored in the organizational secret GE_ACCESS_TOKEN. For
security, GitHub Actions do not pass secrets to runners running
workflows triggered from forked repositories.
So, it's not a problem to setup authentication.
On a separate note, we can also setup a shared gradle cache (something
like https://iceberg-cache.apache.org/cache/), but that's another
topic :)
Regards
JB
On Mon, Nov 25, 2024 at 12:58 PM Robert Stupp <sn...@snazy.de> wrote:
It's tricky - have to use a mixture actually, as I notes in
https://github.com/apache/polaris/pull/475#issuecomment-2497792648 : "Apache's
instance rejects unauthenticated build scans, which is always the case for PR CI runs (no
secrets in those GH workflows). So I think it's fine to let CI runs that don't have the
access-key secret publish to Gradle's infra, and those that have it publish to Apache's
infra."
On 25.11.24 12:39, Eduard Tudenhöfner wrote:
I think that's a good idea, so +1 from my side.
On Mon, Nov 25, 2024 at 11:10 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
Hi folks,
The ASF is hosting a Gradle Develocity instance where we can store our
build scans.
It's hosted on https://ge.apache.org.
Several projects are using it (Apache Beam, Apache Pekko, etc).
Build scans collect information about a build, including the actual
output of failed tests.
It's convenient to investigate test failures (in our GH Actions) and
Gradle plugins executions.
I'm proposing to export/store our build scans on ASF Develocity.
Thoughts ?
Regards
JB
--
Robert Stupp
@snazy
--
Robert Stupp
@snazy
