Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Make error message more actionable

    • -2
    • +2
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
  1. … 1 more file in changeset.
Create a different verification file if dry run is on

This commit is another usability issue: this allows simulating

the write of a verification file by resolving all configurations,

but instead of modifying the file it actually generates a different

one which can then be used for diff'ing.

This can be useful whenever the user wants to have comments and a

specific order in their verification file and want to merge the

diff by hand. It's also useful to avoid having to actually execute

the build to check if all configurations would be ok.

    • -0
    • +103
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 3 more files in changeset.
Create a different verification file if dry run is on

This commit is another usability issue: this allows simulating

the write of a verification file by resolving all configurations,

but instead of modifying the file it actually generates a different

one which can then be used for diff'ing.

This can be useful whenever the user wants to have comments and a

specific order in their verification file and want to merge the

diff by hand. It's also useful to avoid having to actually execute

the build to check if all configurations would be ok.

    • -0
    • +103
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 3 more files in changeset.
Ignore trusted modules when writing the file

This is particularly useful when you want to ignore some modules

in the output file (for example, the native-platform snapshots)

but don't want them to appear in the verification file either.

The checking is also slightly changed so that we would only check

if a module is trusted if there's actually a verification error.

    • -0
    • +83
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 4 more files in changeset.
Ignore trusted modules when writing the file

This is particularly useful when you want to ignore some modules

in the output file (for example, the native-platform snapshots)

but don't want them to appear in the verification file either.

The checking is also slightly changed so that we would only check

if a module is trusted if there's actually a verification error.

    • -0
    • +83
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 4 more files in changeset.
Improve error handling when the verification file cannot be read

Before this change, a failure to read the file would prevent the

services from being initialized, which wasn't user friendly. Now

the error is deferred when the actual resolution happens.

    • -0
    • +21
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
  1. … 1 more file in changeset.
Improve error handling when the verification file cannot be read

Before this change, a failure to read the file would prevent the

services from being initialized, which wasn't user friendly. Now

the error is deferred when the actual resolution happens.

    • -0
    • +21
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
  1. … 1 more file in changeset.
Mark test as to be fixed for instant execution

    • -0
    • +1
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
Mark test as to be fixed for instant execution

    • -0
    • +1
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
Fix merge conflict

    • -2
    • +10
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 2 more files in changeset.
Fix merge conflict

    • -2
    • +10
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 2 more files in changeset.
Use ConcurrentTestUtil.poll when asserting WIP state

    • -11
    • +15
    ./resolve/transform/TransformationLoggingIntegrationTest.groovy
Poll for work in progress line in test

instead of using sleep.

    • -11
    • +24
    ./resolve/transform/TransformationLoggingIntegrationTest.groovy
Using BlockingHttpServer to obtain status line

    • -6
    • +14
    ./resolve/transform/TransformationLoggingIntegrationTest.groovy
Using BlockingHttpServer to obtain status line

    • -6
    • +14
    ./resolve/transform/TransformationLoggingIntegrationTest.groovy
Add lenient version of ComponentMetadataDetails.addVariant() (#11565)

    • -10
    • +90
    ./resolve/rules/VariantFilesMetadataRulesIntegrationTest.groovy
  1. … 10 more files in changeset.
Test that transforms print > Transforming

since those messages will be filtered from the build scan logs.

    • -0
    • +50
    ./resolve/transform/TransformationLoggingIntegrationTest.groovy
Make it possible to trust some modules

There are cases where it makes sense to trust some modules.

For example, a company using a frequent release pace may want

to trust their company artifacts (changing often so painful

to update the configuration) more than the external dependencies.

This gives the opportunity to tell what are the trusted modules.

The configuration requires at least a group name, but modules

can be trusted on the whole (group, name, version, file name)

tuple.

It is also possible to use regular expressions, for example one

could use:

<trust group="com[.]mycompany[.].*"/>

    • -0
    • +30
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
    • -2
    • +9
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 9 more files in changeset.
Make it possible to trust some modules

There are cases where it makes sense to trust some modules.

For example, a company using a frequent release pace may want

to trust their company artifacts (changing often so painful

to update the configuration) more than the external dependencies.

This gives the opportunity to tell what are the trusted modules.

The configuration requires at least a group name, but modules

can be trusted on the whole (group, name, version, file name)

tuple.

It is also possible to use regular expressions, for example one

could use:

<trust group="com[.]mycompany[.].*"/>

    • -0
    • +30
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
    • -2
    • +9
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 9 more files in changeset.
Make it possible to trust some modules

There are cases where it makes sense to trust some modules.

For example, a company using a frequent release pace may want

to trust their company artifacts (changing often so painful

to update the configuration) more than the external dependencies.

This gives the opportunity to tell what are the trusted modules.

The configuration requires at least a group name, but modules

can be trusted on the whole (group, name, version, file name)

tuple.

It is also possible to use regular expressions, for example one

could use:

<trust group="com[.]mycompany[.].*"/>

    • -0
    • +31
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
    • -0
    • +8
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 9 more files in changeset.
Make it possible to trust some modules

There are cases where it makes sense to trust some modules.

For example, a company using a frequent release pace may want

to trust their company artifacts (changing often so painful

to update the configuration) more than the external dependencies.

This gives the opportunity to tell what are the trusted modules.

The configuration requires at least a group name, but modules

can be trusted on the whole (group, name, version, file name)

tuple.

It is also possible to use regular expressions, for example one

could use:

<trust group="com[.]mycompany[.].*"/>

    • -0
    • +31
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
    • -2
    • +9
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 9 more files in changeset.
Make it possible to disable metadata verification

This commit introduces basic configuration for dependency

verification. The only thing that is configurable now is

the ability to disable verification of metadata. This can

be useful whenever the user only wants to trust artifacts,

because addition of metadata in verification files can

be quite verbose.

    • -1
    • +49
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
    • -0
    • +107
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 13 more files in changeset.
Make it possible to disable metadata verification

This commit introduces basic configuration for dependency

verification. The only thing that is configurable now is

the ability to disable verification of metadata. This can

be useful whenever the user only wants to trust artifacts,

because addition of metadata in verification files can

be quite verbose.

    • -1
    • +49
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
    • -0
    • +107
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 13 more files in changeset.
Make it possible to disable metadata verification

This commit introduces basic configuration for dependency

verification. The only thing that is configurable now is

the ability to disable verification of metadata. This can

be useful whenever the user only wants to trust artifacts,

because addition of metadata in verification files can

be quite verbose.

    • -0
    • +49
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
    • -0
    • +106
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 13 more files in changeset.
Fix verification of alternate checksums

    • -0
    • +33
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
  1. … 1 more file in changeset.
Fix writing/verification of alternate checksums

    • -0
    • +33
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
    • -1
    • +60
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 2 more files in changeset.
Fix writing/verification of alternate checksums

    • -0
    • +33
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
    • -1
    • +60
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 2 more files in changeset.
Fix writing/verification of alternate checksums

    • -0
    • +33
    ./resolve/verification/DependencyVerificationIntegrityCheckIntegTest.groovy
    • -1
    • +60
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 2 more files in changeset.
Make verification model more resilient to real world projects

Dogfooding the Gradle build with dependenvy verification proved to

be helpful. There are quite a few cases where we discover dependencies

which come from different repositories. Reposiories can also be mirrored

and sometimes the mirror doesn't mirror what is was supposed to.

The problem is that working around, for example by fixing the mirrors

or figuring out how to fetch a dependency from the right place can be

tricky. It's often easier to go and check the dependency and/or metadata

and approve it.

For this purpose, the verification metadata file now includes the

ability to have "alternate", trusted checksums. It also adds the ability

to tell where a checksum comes from, as indication to the reader. Checksums

generated by Gradle will be marked as such, and therefore a reader can

see that they are less "trustworthy" than checksums fetched by a human.

    • -24
    • +23
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 12 more files in changeset.
Make verification model more resilient to real world projects

Dogfooding the Gradle build with dependenvy verification proved to

be helpful. There are quite a few cases where we discover dependencies

which come from different repositories. Reposiories can also be mirrored

and sometimes the mirror doesn't mirror what is was supposed to.

The problem is that working around, for example by fixing the mirrors

or figuring out how to fetch a dependency from the right place can be

tricky. It's often easier to go and check the dependency and/or metadata

and approve it.

For this purpose, the verification metadata file now includes the

ability to have "alternate", trusted checksums. It also adds the ability

to tell where a checksum comes from, as indication to the reader. Checksums

generated by Gradle will be marked as such, and therefore a reader can

see that they are less "trustworthy" than checksums fetched by a human.

    • -24
    • +23
    ./resolve/verification/DependencyVerificationWritingIntegTest.groovy
  1. … 12 more files in changeset.