Michael Kriese
1ea8602aaa
* test(manager): cover twelve else-if branches The trailing `else if` of a chain leaves v8 counting an implicit else that no coverage-ignore hint can suppress. Fourteen of those were marked as structurally unreachable, but only two of them actually are -- each of these twelve has an input that takes it: - `bazel`: an archive url whose file name is only a suffix, which strips to an empty value, so neither value nor digest is set - `cargo`: a `[package]` section with no `version` at all - `composer`: an inline `package` repository, which the discriminated union does carry, contrary to the comment that claimed otherwise - `deps-edn`: an `:mvn/repos` entry whose spec is a plain string - `gomod`: an update where only the `go` directive changed, leaving no additional dependencies to count - `helmfile`: a release with an empty chart name, which is neither a local path nor an oci ref and yields an empty repo name - `nuget`: a lock file that is gone after the restore - `swift`: a comma where `from` expects a colon, and where `from:` expects a version -- both are labels the state machine searches for and then ignores - `terraform`: a module source too short to be a registry module - `tflint-plugin`: a quoted attribute that is neither version nor source - `travis`: a matrix `node_js` that is a number The stale comments go with them. Three more in `swift` were already wrong before this change: the branches they described were covered. Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io> * refactor(manager): collapse two exhaustive else-if chains `glasskube` and `gradle` were the only two of the fourteen trailing `else if` branches that really are unreachable, and both are provable from a type rather than from a reading of the surrounding code: - `glasskube` parses resources with a schema that admits exactly `Package`, `ClusterPackage` and `PackageRepository`, and filters anything else out - `gradle`'s `ContentDescriptorSpec.mode` is `'include' | 'exclude'` Turning the final `else if` into a plain `else` drops the phantom branch v8 was counting. With these, the manager tree reaches 100% branch coverage. The glasskube check is inverted so that the single-literal discriminant narrows for the compiler. Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io> * test(manager/travis): inline the numeric node_js fixture The three-line fixture went into `__fixtures__` only because every other fixture in this spec is loaded through `Fixtures.get`. A reader of the test should be able to see the input without opening a second file, so write it inline with `codeBlock`. Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io> --------- Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
The gradle manager uses a custom parser written in JavaScript, similar to many others managers.
It does not call gradle directly in order to extract a list of dependencies.
Executing the Gradle Wrapper
Renovate will only execute the Gradle Wrapper (via ./gradlew or gradlew.bat) if the self-hosted administrator configures allowedUnsafeExecutions to include the gradleWrapper option.
This is required due to possible supply chain security attack vectors that can occur with the Gradle Wrapper being executed.
Updating lockfiles
The gradle manager supports gradle lock files in .lockfile artifacts, as well as lock files used by the gradle-consistent-versions plugin.
During lock file maintenance, renovate calls ./gradlew :dependencies --write-locks on the root project and subprojects.
For regular dependency updates, renovate automatically updates lock state entries via the --update-locks command line flag.
As the output of these commands can be very large, any text other than errors (in stderr) is discarded.
Dependency verification
Renovate supports Gradle's dependency verification functionality to ensure that checksums are calculated for your dependencies.
!!! note This requires your self-hosted administrator to allow the Gradle Wrapper to execute.
If Renovate finds a gradle/verification-metadata.xml file and either <verify-metadata>true</verify-metadata> or <verify-signatures>true</verify-signatures> (or both), it updates the content by using the ./gradlew --write-verification-metadata <hashTypes> dependencies command.
Renovate will check the file for existing hash types (like sha256) and use them as <hashTypes>.
!!! warning
Gradle allows verification metadata to use the md5 and sha1 algorithms.
Because those algorithms are prone to collision attacks, Renovate ignores them.
If Renovate encounters hashes that are generated with md5 or sha1 algorithms, Renovate uses sha256 instead.