Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Use org.gradle.api.credentials.PasswordCredentials internally

org.gradle.api.artifacts.repositories.PasswordCredentials was where PasswordCredentials originated before being moved to org.gradle.api.credentials package together with other Credentials implementations.

After this change org.gradle.api.artifacts.repositories.PasswordCredentials will remain to be used only in the public APIs around repositories.

Once its surface area is reduced, we might be able to deprecate it in favor of org.gradle.api.credentials.PasswordCredentials in a subsequent change.

  1. … 16 more files in changeset.
Added integration tests to make sure retries happen for maven and ivy publication

Signed-off-by: Roberto Perez Alcolea <rperezalcolea@netflix.com>

  1. … 6 more files in changeset.
Initial implementation of verification of signatures

This commit introduces _signature_ verification. Signature verification

is stronger than checksum verification and must be enabled explicitly,

by adding `<signature-verification>true</signature-verification>` to the

dependency verification configuration file.

Once such verification is enabled, Gradle will do its best to verify

the signature of artifacts. This means:

- it will try to download the .asc file associated with an artifact

- if it's present, it will automatically download the public keys

of the signature and verify that the file matches the signatures

- if _any_ of the signature verification fails, fails the build

- if a public key is not trusted explicitly, fails the build

- if signature verification succeeds, no checksum verification is

performed

Currently it's not possible to perform checksum verification for some

modules and signature verification for others. All modules must declare

all trusted keys.

If a key cannot be downloaded, verification will fail. It's not possible

to ignore a key for now. It's not possible to fallback to checksum

verification.

  1. … 63 more files in changeset.
Initial implementation of verification of signatures

This commit introduces _signature_ verification. Signature verification

is stronger than checksum verification and must be enabled explicitly,

by adding `<signature-verification>true</signature-verification>` to the

dependency verification configuration file.

Once such verification is enabled, Gradle will do its best to verify

the signature of artifacts. This means:

- it will try to download the .asc file associated with an artifact

- if it's present, it will automatically download the public keys

of the signature and verify that the file matches the signatures

- if _any_ of the signature verification fails, fails the build

- if a public key is not trusted explicitly, fails the build

- if signature verification succeeds, no checksum verification is

performed

Currently it's not possible to perform checksum verification for some

modules and signature verification for others. All modules must declare

all trusted keys.

If a key cannot be downloaded, verification will fail. It's not possible

to ignore a key for now. It's not possible to fallback to checksum

verification.

  1. … 62 more files in changeset.
Initial implementation of verification of signatures

This commit introduces _signature_ verification. Signature verification

is stronger than checksum verification and must be enabled explicitly,

by adding `<signature-verification>true</signature-verification>` to the

dependency verification configuration file.

Once such verification is enabled, Gradle will do its best to verify

the signature of artifacts. This means:

- it will try to download the .asc file associated with an artifact

- if it's present, it will automatically download the public keys

of the signature and verify that the file matches the signatures

- if _any_ of the signature verification fails, fails the build

- if a public key is not trusted explicitly, fails the build

- if signature verification succeeds, no checksum verification is

performed

Currently it's not possible to perform checksum verification for some

modules and signature verification for others. All modules must declare

all trusted keys.

If a key cannot be downloaded, verification will fail. It's not possible

to ignore a key for now. It's not possible to fallback to checksum

verification.

  1. … 61 more files in changeset.
Initial implementation of verification of signatures

This commit introduces _signature_ verification. Signature verification

is stronger than checksum verification and must be enabled explicitly,

by adding `<signature-verification>true</signature-verification>` to the

dependency verification configuration file.

Once such verification is enabled, Gradle will do its best to verify

the signature of artifacts. This means:

- it will try to download the .asc file associated with an artifact

- if it's present, it will automatically download the public keys

of the signature and verify that the file matches the signatures

- if _any_ of the signature verification fails, fails the build

- if a public key is not trusted explicitly, fails the build

- if signature verification succeeds, no checksum verification is

performed

Currently it's not possible to perform checksum verification for some

modules and signature verification for others. All modules must declare

all trusted keys.

If a key cannot be downloaded, verification will fail. It's not possible

to ignore a key for now. It's not possible to fallback to checksum

verification.

  1. … 63 more files in changeset.
Initial implementation of verification of signatures

This commit introduces _signature_ verification. Signature verification

is stronger than checksum verification and must be enabled explicitly,

by adding `<signature-verification>true</signature-verification>` to the

dependency verification configuration file.

Once such verification is enabled, Gradle will do its best to verify

the signature of artifacts. This means:

- it will try to download the .asc file associated with an artifact

- if it's present, it will automatically download the public keys

of the signature and verify that the file matches the signatures

- if _any_ of the signature verification fails, fails the build

- if a public key is not trusted explicitly, fails the build

- if signature verification succeeds, no checksum verification is

performed

Currently it's not possible to perform checksum verification for some

modules and signature verification for others. All modules must declare

all trusted keys.

If a key cannot be downloaded, verification will fail. It's not possible

to ignore a key for now. It's not possible to fallback to checksum

verification.

  1. … 63 more files in changeset.
Make http server fixture's handle() thread safe

As stated in the here implemented 'ServerWithExpectations' fixture:

"handlers, as well as failures, need to be thread-safe"

This concrete case was working most of the time since usually there are

not more than one expectations for the same request. But if the

same request is expected several times, and the requests are received

in parallel (as it is the case for metadata download), the handle()

method behaved flaky - by not doing reading and updating of the 'run'

flag as an atomic operation.

  1. … 4 more files in changeset.
Make http server fixture's handle() thread safe

As stated in the here implemented 'ServerWithExpectations' fixture:

"handlers, as well as failures, need to be thread-safe"

This concrete case was working most of the time since usually there are

not more than one expectations for the same request. But if the

same request is expected several times, and the requests are received

in parallel (as it is the case for metadata download), the handle()

method behaved flaky - by not doing reading and updating of the 'run'

flag as an atomic operation.

  1. … 4 more files in changeset.
Make http server fixture's handle() thread safe

As stated in the here implemented 'ServerWithExpectations' fixture:

"handlers, as well as failures, need to be thread-safe"

This concrete case was working most of the time since usually there are

not more than one expectations for the same request. But if the

same request is expected several times, and the requests are received

in parallel (as it is the case for metadata download), the handle()

method behaved flaky - by not doing reading and updating of the 'run'

flag as an atomic operation.

  1. … 4 more files in changeset.
Make http server fixture's handle() thread safe

As stated in the here implemented 'ServerWithExpectations' fixture:

"handlers, as well as failures, need to be thread-safe"

This concrete case was working most of the time since usually there are

not more than one expectations for the same request. But if the

same request is expected several times, and the requests are received

in parallel (as it is the case for metadata download), the handle()

method behaved flaky - by not doing reading and updating of the 'run'

flag as an atomic operation.

  1. … 4 more files in changeset.
Add more synchronization to http server fixture

As stated in the here implemented 'ServerWithExpectations' fixture:

"handlers, as well as failures, need to be thread-safe"

This concrete case was working most of the time since usually there are

not more than one expectations for the same request. But if the

same request is expected several times, and the requests are received

in parallel (as it is the case for metadata download), the handle

method behaved flaky.

Avoid assertion error in HttpServer.toString

Co-Authored-By: Jonathan Leitschuh <Jonathan.Leitschuh@gradle.com>

Make all HttpServer.expect methods use the same base method to uniformly enforce credential checks

Reject Http requests with unexpected credentials

  1. … 1 more file in changeset.
Fix integration tests

  1. … 3 more files in changeset.
Fix integration tests

  1. … 3 more files in changeset.
Fix integration tests

  1. … 3 more files in changeset.
Revert "Revert "Un-ignore Https wrapper test""

This reverts commit bf101fea1239890c7cd26bc4c4a12d68c03f6154.

  1. … 1 more file in changeset.
Revert "Revert "Un-ignore Https wrapper test""

This reverts commit bf101fea1239890c7cd26bc4c4a12d68c03f6154.

  1. … 1 more file in changeset.
Revert "Un-ignore Https wrapper test"

This reverts commit ea08ddcff92a93e1326cc49b63100da98c84fb0e.

  1. … 1 more file in changeset.
Un-ignore Https wrapper test

  1. … 1 more file in changeset.
Revert "Don't ignore InterruptedException"

This reverts commit bc1ad17d58d7afec51478b08ef7a4c29daf96ca7.

Don't ignore InterruptedException

Previously we ignored the InterruptedException, which may shadow other real problems.

For example, a test expect the server to block 60 seconds, but somehome it's interrupted

and actually blocks only 1 second, the test might behave weird or flaky. Now we simply

remove the catch block.

Reduce visibility of some test fixture types.

  1. … 3 more files in changeset.
Migrate to Jetty 9

  1. … 20 more files in changeset.
Use `Assume` to ignore tests rather than allowing failure

  1. … 3 more files in changeset.
Migrate `ComponentSelectorRulesDependencyResolveIntegTest` to cross-repository test fixtures

  1. … 8 more files in changeset.
Gradle should fail resolution from subsequent repositories on critical errors (#3412)

  1. … 15 more files in changeset.
Revert "Revert "Introduce HTTP timeout (#3041)""

This reverts commit 14711361a0cb6beb3a57766804c109ba6f3f87c0.

  1. … 12 more files in changeset.