AbstractDependencyVerificationIntegTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Introduce a terse console output for verification failures

This commit switches from a verbose console output when

dependency verification errors occur, to a terse version

which basically only links to the rich report.

It's still possible to use the verbose output by configuring

the build with the Gradle `org.gradle.dependency.verification.console`

property (usual places apply).

    • -0
    • +8
    ./AbstractDependencyVerificationIntegTest.groovy
  1. … 12 more files in changeset.
Make some error messages clearer

    • -0
    • +5
    ./AbstractDependencyVerificationIntegTest.groovy
  1. … 4 more files in changeset.
Make some error messages clearer

    • -0
    • +5
    ./AbstractDependencyVerificationIntegTest.groovy
  1. … 4 more files in changeset.
Add a signature verification cache

This cache avoids re-checking signatures on every build, or even for

the same file multiple times during a build.

    • -1
    • +1
    ./AbstractDependencyVerificationIntegTest.groovy
  1. … 10 more files in changeset.
Add a signature verification cache

This cache avoids re-checking signatures on every build, or even for

the same file multiple times during a build.

    • -1
    • +1
    ./AbstractDependencyVerificationIntegTest.groovy
  1. … 12 more files in changeset.
Add a signature verification cache

This cache avoids re-checking signatures on every build, or even for

the same file multiple times during a build.

    • -1
    • +1
    ./AbstractDependencyVerificationIntegTest.groovy
  1. … 12 more files in changeset.
Add logging of the test path

This is done in order to debug checksums failing on CI

    • -1
    • +2
    ./AbstractDependencyVerificationIntegTest.groovy
Always serialize module sources

Module sources were only serialized in the cache metadata entry.

In practice, they belong to the module metadata, so they are now

properly serialized as part of it. This fixes the "force realize"

tests.

    • -1
    • +2
    ./AbstractDependencyVerificationIntegTest.groovy
  1. … 18 more files in changeset.
Always serialize module sources

Module sources were only serialized in the cache metadata entry.

In practice, they belong to the module metadata, so they are now

properly serialized as part of it. This fixes the "force realize"

tests.

    • -1
    • +2
    ./AbstractDependencyVerificationIntegTest.groovy
  1. … 18 more files in changeset.
Always serialize module sources

Module sources were only serialized in the cache metadata entry.

In practice, they belong to the module metadata, so they are now

properly serialized as part of it. This fixes the "force realize"

tests.

    • -1
    • +2
    ./AbstractDependencyVerificationIntegTest.groovy
  1. … 18 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
    ./AbstractDependencyVerificationIntegTest.groovy
  1. … 7 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
    ./AbstractDependencyVerificationIntegTest.groovy
  1. … 7 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
    ./AbstractDependencyVerificationIntegTest.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
    ./AbstractDependencyVerificationIntegTest.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
    ./AbstractDependencyVerificationIntegTest.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
    ./AbstractDependencyVerificationIntegTest.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

    • -0
    • +11
    ./AbstractDependencyVerificationIntegTest.groovy
  1. … 6 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
    ./AbstractDependencyVerificationIntegTest.groovy
  1. … 5 more files in changeset.
Generate checksum file for dependency verification

This commit introduces the generation of a dependency

verification metadata file from the CLI. If the user

calls `--write-verification-metadata`, then an XML

file is generated (`gradle/verification-metadata.xml`).

This file will contain the checksums for all artifacts

required by a build, which includes:

- plugin artifacts

- jars and other artifacts requested via a `configuration`

- secondary artifacts (javadocs, classifiers, ...)

It does NOT include metadata of those artifacts (pom files,

ivy files, Gradle Module metadata).

It isn't required to resolve any configuration to get this

behavior: the build will automatically process all resolvable

configurations and _try_ to resolve them automatically. All

artifacts resolved during this process are going to be automatically

downloaded (if not already). Then SHA-1 and SHA-512 checksums

are computed for all those artifacts.

The current format is an XML file planned to support more than

just artifacts: module metadata AND signature information is

planned.

See #11398

    • -0
    • +77
    ./AbstractDependencyVerificationIntegTest.groovy
  1. … 32 more files in changeset.
Generate checksum file for dependency verification

This commit introduces the generation of a dependency

verification metadata file from the CLI. If the user

calls `--write-verification-metadata`, then an XML

file is generated (`gradle/verification-metadata.xml`).

This file will contain the checksums for all artifacts

required by a build, which includes:

- plugin artifacts

- jars and other artifacts requested via a `configuration`

- secondary artifacts (javadocs, classifiers, ...)

It does NOT include metadata of those artifacts (pom files,

ivy files, Gradle Module metadata).

It isn't required to resolve any configuration to get this

behavior: the build will automatically process all resolvable

configurations and _try_ to resolve them automatically. All

artifacts resolved during this process are going to be automatically

downloaded (if not already). Then SHA-1 and SHA-512 checksums

are computed for all those artifacts.

The current format is an XML file planned to support more than

just artifacts: module metadata AND signature information is

planned.

See #11398

    • -0
    • +77
    ./AbstractDependencyVerificationIntegTest.groovy
  1. … 32 more files in changeset.
Generate checksum file for dependency verification

This commit introduces the generation of a dependency

verification metadata file from the CLI. If the user

calls `--write-verification-metadata`, then an XML

file is generated (`gradle/verification-metadata.xml`).

This file will contain the checksums for all artifacts

required by a build, which includes:

- plugin artifacts

- jars and other artifacts requested via a `configuration`

- secondary artifacts (javadocs, classifiers, ...)

It does NOT include metadata of those artifacts (pom files,

ivy files, Gradle Module metadata).

It isn't required to resolve any configuration to get this

behavior: the build will automatically process all resolvable

configurations and _try_ to resolve them automatically. All

artifacts resolved during this process are going to be automatically

downloaded (if not already). Then SHA-1 and SHA-512 checksums

are computed for all those artifacts.

The current format is an XML file planned to support more than

just artifacts: module metadata AND signature information is

planned.

See #11398

    • -0
    • +77
    ./AbstractDependencyVerificationIntegTest.groovy
  1. … 32 more files in changeset.
Generate checksum file for dependency verification

This commit introduces the generation of a dependency

verification metadata file from the CLI. If the user

calls `--write-verification-metadata`, then an XML

file is generated (`gradle/verification-metadata.xml`).

This file will contain the checksums for all artifacts

required by a build, which includes:

- plugin artifacts

- jars and other artifacts requested via a `configuration`

- secondary artifacts (javadocs, classifiers, ...)

It does NOT include metadata of those artifacts (pom files,

ivy files, Gradle Module metadata).

It isn't required to resolve any configuration to get this

behavior: the build will automatically process all resolvable

configurations and _try_ to resolve them automatically. All

artifacts resolved during this process are going to be automatically

downloaded (if not already). Then SHA-1 and SHA-512 checksums

are computed for all those artifacts.

The current format is an XML file planned to support more than

just artifacts: module metadata AND signature information is

planned.

See #11398

    • -0
    • +77
    ./AbstractDependencyVerificationIntegTest.groovy
  1. … 32 more files in changeset.
Generate checksum file for dependency verification

This commit introduces the generation of a dependency

verification metadata file from the CLI. If the user

calls `--write-verification-metadata`, then an XML

file is generated (`gradle/verification-metadata.xml`).

This file will contain the checksums for all artifacts

required by a build, which includes:

- plugin artifacts

- jars and other artifacts requested via a `configuration`

- secondary artifacts (javadocs, classifiers, ...)

It does NOT include metadata of those artifacts (pom files,

ivy files, Gradle Module metadata).

It isn't required to resolve any configuration to get this

behavior: the build will automatically process all resolvable

configurations and _try_ to resolve them automatically. All

artifacts resolved during this process are going to be automatically

downloaded (if not already). Then SHA-1 and SHA-512 checksums

are computed for all those artifacts.

The current format is an XML file planned to support more than

just artifacts: module metadata AND signature information is

planned.

See #11398

    • -0
    • +77
    ./AbstractDependencyVerificationIntegTest.groovy
  1. … 32 more files in changeset.
Generate checksum file for dependency verification

This commit introduces the generation of a dependency

verification metadata file from the CLI. If the user

calls `--write-verification-metadata`, then an XML

file is generated (`gradle/verification-metadata.xml`).

This file will contain the checksums for all artifacts

required by a build, which includes:

- plugin artifacts

- jars and other artifacts requested via a `configuration`

- secondary artifacts (javadocs, classifiers, ...)

It does NOT include metadata of those artifacts (pom files,

ivy files, Gradle Module metadata).

It isn't required to resolve any configuration to get this

behavior: the build will automatically process all resolvable

configurations and _try_ to resolve them automatically. All

artifacts resolved during this process are going to be automatically

downloaded (if not already). Then SHA-1 and SHA-512 checksums

are computed for all those artifacts.

The current format is an XML file planned to support more than

just artifacts: module metadata AND signature information is

planned.

See #11398

    • -0
    • +77
    ./AbstractDependencyVerificationIntegTest.groovy
  1. … 32 more files in changeset.
Generate checksum file for dependency verification

This commit introduces the generation of a dependency

verification metadata file from the CLI. If the user

calls `--write-verification-metadata`, then an XML

file is generated (`gradle/verification-metadata.xml`).

This file will contain the checksums for all artifacts

required by a build, which includes:

- plugin artifacts

- jars and other artifacts requested via a `configuration`

- secondary artifacts (javadocs, classifiers, ...)

It does NOT include metadata of those artifacts (pom files,

ivy files, Gradle Module metadata).

It isn't required to resolve any configuration to get this

behavior: the build will automatically process all resolvable

configurations and _try_ to resolve them automatically. All

artifacts resolved during this process are going to be automatically

downloaded (if not already). Then SHA-1 and SHA-512 checksums

are computed for all those artifacts.

The current format is an XML file planned to support more than

just artifacts: module metadata AND signature information is

planned.

See #11398

    • -0
    • +77
    ./AbstractDependencyVerificationIntegTest.groovy
  1. … 32 more files in changeset.