clayburn commented on PR #39708: URL: https://github.com/apache/arrow/pull/39708#issuecomment-1900919170
> Thank you @clayburn! This is an exciting improvement. For local build execution, would we have to change anything in our developer docs[1] on how to build Arrow java in order to take advantage of this? > > [1]https://arrow.apache.org/docs/developers/java/building.html#building-java-modules @danepitkin - For caching, there is no action needed. The one stipulation that should be noted is that the local cache is machine local, so with some of your containerized builds, it would be local to the container itself without any special handling. The local cache by default is located at `$HOME/.m2/.gradle-enterprise/build-cache`. For build scans, you won't see any changes unless you explicitly authenticate to https://ge.apache.org. Instructions to do so are [here](https://docs.gradle.com/enterprise/maven-extension/#authenticating_with_gradle_enterprise). All ASF committers can authenticate to ge.apache.org with LDAP credentials. Contributors cannot authenticate, so they won't see anything regarding build scans. The access key is either stored in `~/.m2` or pulled from an env var, so again, the containerized builds may not authenticate easily without intention from the user. > @clayburn I have approved the CI runs, I assume that only builds on main will be able to upload data due to the use of secrets? For similar things I have used a two step process in the past where the unprivileged workflow creates the data/artifacts and a second privileged workflow that doesn't run any user code would upload the data. Is this something gradle could support? Or maybe data for each PR build would be a bit much ^^ Build scans will only be produced for builds that run from the `apache/arrow` repo. In other words, not from forks. Forked builds will still build just fine, but will not produce a scan. We are working on methods to handle this in the way you described, performing the upload of the scan in a "trusted" environment, but this is not yet ready. The caching functionality will work without the secret, although the benefits may not be apparent in your CI builds since they are presumably running on ephemeral agents and the cache is machine local. This is where the remote cache will help more, which we hope to enable in the future. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
