Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Add lenient dependency verification mode

This mode has been added because dogfooding the feature showed

it could be painful to udpate the dependency verification

metadata file without such an option: often we want to diagnose

why a dependency is here, but as soon as the dependency

verification file is present, verification is active and immediately

fails the build.

This effectively prevents from using the usual tooling to check

where a dependency comes from. The workaround was to temporarily

rename the file, run the build, then rename again, which was tedious.

So, instead of adding a mode where verification would be totally

ignored, this commit introduces a mode where the errors are turned

into warnings. This doesn't totally silence the problems, which

makes them more visible to the developer.

    • -0
    • +25
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
  1. … 5 more files in changeset.
Document current behavior of writing parent POM file verification

The current implementation of dependency verification metadata

generation computes POM metadata verification checksums for parent

POMs, _only when they are downloaded during the same build_.

This behavior is an artifact of how parent POM resolution is

implemented. Eventually, all metadata should be considered equal

and have metadata written in the verification file.

    • -0
    • +78
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 1 more file in changeset.
Improve message for invalid configuration mutation

This now indicates what is being modified is a "dependency

configuration". Also what is being modified is now more explicit in some

cases.

    • -4
    • +4
    ./resolve/OutgoingVariantsMutationIntegrationTest.groovy
    • -2
    • +2
    ./resolve/ProjectDependencyResolveIntegrationTest.groovy
    • -1
    • +1
    ./resolve/api/ConfigurationDefaultsIntegrationTest.groovy
    • -2
    • +2
    ./resolve/api/ConfigurationMutationIntegrationTest.groovy
    • -22
    • +22
    ./resolve/api/UnsupportedConfigurationMutationTest.groovy
  1. … 5 more files in changeset.
Improve message for invalid configuration mutation

This now indicates what is being modified is a "dependency

configuration". Also what is being modified is now more explicit in some

cases.

    • -4
    • +4
    ./resolve/OutgoingVariantsMutationIntegrationTest.groovy
    • -2
    • +2
    ./resolve/ProjectDependencyResolveIntegrationTest.groovy
    • -1
    • +1
    ./resolve/api/ConfigurationDefaultsIntegrationTest.groovy
    • -2
    • +2
    ./resolve/api/ConfigurationMutationIntegrationTest.groovy
    • -22
    • +22
    ./resolve/api/UnsupportedConfigurationMutationTest.groovy
  1. … 5 more files in changeset.
Improve message for invalid configuration mutation

This now indicates what is being modified is a "dependency

configuration". Also what is being modified is now more explicit in some

cases.

    • -4
    • +4
    ./resolve/OutgoingVariantsMutationIntegrationTest.groovy
    • -2
    • +2
    ./resolve/ProjectDependencyResolveIntegrationTest.groovy
    • -1
    • +1
    ./resolve/api/ConfigurationDefaultsIntegrationTest.groovy
    • -2
    • +2
    ./resolve/api/ConfigurationMutationIntegrationTest.groovy
    • -22
    • +22
    ./resolve/api/UnsupportedConfigurationMutationTest.groovy
  1. … 5 more files in changeset.
Improve message for invalid configuration mutation

This now indicates what is being modified is a "dependency

configuration". Also what is being modified is now more explicit in some

cases.

    • -4
    • +4
    ./resolve/OutgoingVariantsMutationIntegrationTest.groovy
    • -2
    • +2
    ./resolve/ProjectDependencyResolveIntegrationTest.groovy
    • -1
    • +1
    ./resolve/api/ConfigurationDefaultsIntegrationTest.groovy
    • -2
    • +2
    ./resolve/api/ConfigurationMutationIntegrationTest.groovy
    • -22
    • +22
    ./resolve/api/UnsupportedConfigurationMutationTest.groovy
  1. … 5 more files in changeset.
Improve message for invalid configuration mutation

This now indicates what is being modified is a "dependency

configuration". Also what is being modified is now more explicit in some

cases.

    • -4
    • +4
    ./resolve/OutgoingVariantsMutationIntegrationTest.groovy
    • -2
    • +2
    ./resolve/ProjectDependencyResolveIntegrationTest.groovy
    • -1
    • +1
    ./resolve/api/ConfigurationDefaultsIntegrationTest.groovy
    • -2
    • +2
    ./resolve/api/ConfigurationMutationIntegrationTest.groovy
    • -22
    • +22
    ./resolve/api/UnsupportedConfigurationMutationTest.groovy
  1. … 5 more files in changeset.
Improve message for invalid configuration mutation

This now indicates what is being modified is a "dependency

configuration". Also what is being modified is now more explicit in some

cases.

    • -4
    • +4
    ./resolve/OutgoingVariantsMutationIntegrationTest.groovy
    • -2
    • +2
    ./resolve/ProjectDependencyResolveIntegrationTest.groovy
    • -1
    • +1
    ./resolve/api/ConfigurationDefaultsIntegrationTest.groovy
    • -2
    • +2
    ./resolve/api/ConfigurationMutationIntegrationTest.groovy
    • -22
    • +22
    ./resolve/api/UnsupportedConfigurationMutationTest.groovy
  1. … 5 more files in changeset.
Add missing test exclusions for instant execution

    • -0
    • +4
    ./resolve/locking/AbstractLockingIntegrationTest.groovy
    • -0
    • +3
    ./resolve/locking/DependencyLockingLenientModeIntegrationTest.groovy
    • -0
    • +4
    ./resolve/locking/DependencyLockingStrictModeIntegrationTest.groovy
Add missing test exclusions for instant execution

    • -0
    • +4
    ./resolve/locking/AbstractLockingIntegrationTest.groovy
    • -0
    • +3
    ./resolve/locking/DependencyLockingLenientModeIntegrationTest.groovy
    • -0
    • +4
    ./resolve/locking/DependencyLockingStrictModeIntegrationTest.groovy
Remove @ToBeFixedForInstantExecution for test that seems to be passing

    • -1
    • +0
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
Map 'belongsTo()' for published platforms to platform dependency rule

belongsTo for publish platforms did not work properly for all cases

as virtual edges do not carry the requested attribute

'category=platform'. With this commit, the 'belongsTo' functionality

is now only used for virtual platforms, where the platform itself does

not exist as a real node in the graph.

For published platforms, we map the 'belongsTo' call to a rule that

adds a normal platform dependency to the component. This will then

be resolved as any other platform dependency. An advantage is also

that the resolution result will contain all the added edges. Before,

the combination of an existing platform with virtual edges (not

shown in the result) was confusing.

    • -31
    • +105
    ./resolve/alignment/AlignmentIntegrationTest.groovy
    • -69
    • +34
    ./resolve/alignment/ForcingPlatformAlignmentTest.groovy
  1. … 1 more file in changeset.
Map 'belongsTo()' for published platforms to platform dependency rule

belongsTo for publish platforms did not work properly for all cases

as virtual edges do not carry the requested attribute

'category=platform'. With this commit, the 'belongsTo' functionality

is now only used for virtual platforms, where the platform itself does

not exist as a real node in the graph.

For published platforms, we map the 'belongsTo' call to a rule that

adds a normal platform dependency to the component. This will then

be resolved as any other platform dependency. An advantage is also

that the resolution result will contain all the added edges. Before,

the combination of an existing platform with virtual edges (not

shown in the result) was confusing.

    • -31
    • +105
    ./resolve/alignment/AlignmentIntegrationTest.groovy
    • -69
    • +34
    ./resolve/alignment/ForcingPlatformAlignmentTest.groovy
  1. … 1 more file in changeset.
Add missing test case for `buildSrc`

This commit introduces a test to prove that `buildSrc`

is also checked, although in practice it's an included

build which is also tested in a separate test case.

    • -0
    • +33
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
  1. … 1 more file in changeset.
Add missing test case for `buildSrc`

This commit introduces a test to prove that `buildSrc`

is also checked, although in practice it's an included

build which is also tested in a separate test case.

    • -0
    • +33
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
  1. … 1 more file in changeset.
Rewrite test for clarity

    • -27
    • +30
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
Rewrite test for clarity

    • -27
    • +30
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
Add missing verification for artifact resolution query

    • -7
    • +50
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
  1. … 4 more files in changeset.
Add missing verification for artifact resolution query

    • -7
    • +50
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
  1. … 4 more files in changeset.
Add missing verification for artifact resolution query

    • -7
    • +50
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
  1. … 4 more files in changeset.
Fail eagerly when accessing artifacts

This commit reworks the moment when we fail because of a dependency

verification error: instead of failing at the end at the build, we

fail immediately after trying to access an artifact.

Because it's effectively impossible to do something with the artifacts

before _all_ artifacts of an artifact collection have been accessed

(because of how Gradle resolves file collections), we can collect as

much errors as possible during the resolution of a configuration and

fail immediately after, which is more user friendly than failing on

each artifact of a set.

    • -8
    • +48
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
  1. … 6 more files in changeset.
Fail eagerly when accessing artifacts

This commit reworks the moment when we fail because of a dependency

verification error: instead of failing at the end at the build, we

fail immediately after trying to access an artifact.

Because it's effectively impossible to do something with the artifacts

before _all_ artifacts of an artifact collection have been accessed

(because of how Gradle resolves file collections), we can collect as

much errors as possible during the resolution of a configuration and

fail immediately after, which is more user friendly than failing on

each artifact of a set.

    • -8
    • +48
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
  1. … 6 more files in changeset.
Fail eagerly when accessing artifacts

This commit reworks the moment when we fail because of a dependency

verification error: instead of failing at the end at the build, we

fail immediately after trying to access an artifact.

Because it's effectively impossible to do something with the artifacts

before _all_ artifacts of an artifact collection have been accessed

(because of how Gradle resolves file collections), we can collect as

much errors as possible during the resolution of a configuration and

fail immediately after, which is more user friendly than failing on

each artifact of a set.

    • -8
    • +48
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
  1. … 6 more files in changeset.
Mark tests failing with instant execution

    • -4
    • +7
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
Mark tests failing with instant execution

    • -4
    • +7
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
Make selection of checksum algorithms mandatory

Instead of using a default list, the user has to choose

what checksums to generate when bootstrapping the dependency

verification file.

This is done because it will have an impact when checking

the dependencies: all checksums will be verified.

    • -2
    • +2
    ./resolve/verification/AbstractDependencyVerificationIntegTest.groovy
    • -559
    • +0
    ./resolve/verification/DependencyVerificationIntegTest.groovy
    • -0
    • +595
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 5 more files in changeset.
Make selection of checksum algorithms mandatory

Instead of using a default list, the user has to choose

what checksums to generate when bootstrapping the dependency

verification file.

This is done because it will have an impact when checking

the dependencies: all checksums will be verified.

    • -2
    • +2
    ./resolve/verification/AbstractDependencyVerificationIntegTest.groovy
    • -559
    • +0
    ./resolve/verification/DependencyVerificationIntegTest.groovy
    • -0
    • +595
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 5 more files in changeset.
Add dependency checksum verification

This commit introduces dependency checksum verification.

If, and only if, a dependency verification metadata file

is present, then Gradle will load this metadata and use

it as the "source of truth" for dependency checksums.

Verification occurs whenever a file is accessed, so it

doesn't matter if the file comes from the local cache

or if it was downloaded in the current build.

Gradle performs all verifications during the build and

fails at the end of the build, similarly to the behavior

for "write dependency verification metadata".

This allows collecting as much information as possible

regarding, typically, the missing checksums, which can

be painful during dependency upgrades.

If a dependency verification file contains multiple

checksums, then _all_ checksums are verified. This is to

avoid the case where one of the checksums is wrong but

not the other, and can be used to further secure verification:

often we only see MD5 and SHA1 checksums. While both can be

baked, it's much harder to bake a dependency which will have

both the same MD5 and SHA1 checksums.

Closes #11399

Closes #4934

    • -0
    • +11
    ./resolve/verification/AbstractDependencyVerificationIntegTest.groovy
    • -0
    • +344
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
    • -13
    • +1
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 3 more files in changeset.
Add dependency checksum verification

This commit introduces dependency checksum verification.

If, and only if, a dependency verification metadata file

is present, then Gradle will load this metadata and use

it as the "source of truth" for dependency checksums.

Verification occurs whenever a file is accessed, so it

doesn't matter if the file comes from the local cache

or if it was downloaded in the current build.

Gradle performs all verifications during the build and

fails at the end of the build, similarly to the behavior

for "write dependency verification metadata".

This allows collecting as much information as possible

regarding, typically, the missing checksums, which can

be painful during dependency upgrades.

If a dependency verification file contains multiple

checksums, then _all_ checksums are verified. This is to

avoid the case where one of the checksums is wrong but

not the other, and can be used to further secure verification:

often we only see MD5 and SHA1 checksums. While both can be

baked, it's much harder to bake a dependency which will have

both the same MD5 and SHA1 checksums.

Closes #11399

Closes #4934

    • -0
    • +11
    ./resolve/verification/AbstractDependencyVerificationIntegTest.groovy
    • -0
    • +344
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
    • -13
    • +1
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 3 more files in changeset.
Add dependency checksum verification

This commit introduces dependency checksum verification.

If, and only if, a dependency verification metadata file

is present, then Gradle will load this metadata and use

it as the "source of truth" for dependency checksums.

Verification occurs whenever a file is accessed, so it

doesn't matter if the file comes from the local cache

or if it was downloaded in the current build.

Gradle performs all verifications during the build and

fails at the end of the build, similarly to the behavior

for "write dependency verification metadata".

This allows collecting as much information as possible

regarding, typically, the missing checksums, which can

be painful during dependency upgrades.

If a dependency verification file contains multiple

checksums, then _all_ checksums are verified. This is to

avoid the case where one of the checksums is wrong but

not the other, and can be used to further secure verification:

often we only see MD5 and SHA1 checksums. While both can be

baked, it's much harder to bake a dependency which will have

both the same MD5 and SHA1 checksums.

Closes #11399

Closes #4934

    • -0
    • +11
    ./resolve/verification/AbstractDependencyVerificationIntegTest.groovy
    • -0
    • +344
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
    • -13
    • +1
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 3 more files in changeset.