Set "gradlew --debug" when SECURE_LOG_LEVEL is set
Release notes
Problem to solve
Our gradlew command currently doesn't add domain-specific debugging flags when the general SECURE_LOG_LEVEL: "debug" is used.
This limits support's and customers' ability to debug build failures/exceptions. For example:
[DEBU] [gemnasium-maven] [… /go/src/app/builder/gradle/gradle.go:115] ▶ /tmp/builds/…/gradlew --init-script /gemnasium-init.gradle gemnasiumDumpDependencies
FAILURE: Build completed with … failures.
1: Task failed with an exception.
-----------
* What went wrong:
Execution failed for task '…:gemnasiumDumpDependencies'.
> Project has 5 unresolved dependencies: …
* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.Currently, customers can try those suggestions by adding them to the *_CLI_OPTS analyzer env vars. Examples where this helped:
-
ZD 531020: Found Gradle-specific parallelization issue
Cannot acquire project lock …gemnasiumDumpDependencies=> gradle#20290.
Proposal
We could preemptively apply the Gradle suggestion there and set --debug (plus --stacktrace and/or --scan) when SECURE_LOG_LEVEL: "debug" is set. For example, gradle.go could receive a SECURE_LOG_LEVEL-conditional append(args, "--debug").
Intended users
Feature Usage Metrics
Fewer Dependency Scanning tickets.
Does this feature require an audit event? No
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.