DependencyUnresolvedModuleIntegrationTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Rename @FailsWithInstantExecution to @ToBeFixedForInstantExecution

Signed-off-by: Paul Merlin <paul@gradle.com>

    • -7
    • +7
    ./DependencyUnresolvedModuleIntegrationTest.groovy
  1. … 872 more files in changeset.
Annotate integ tests failing with instant execution in various projects

removing most of @IgnoreWithInstantExecution annotations

after fixing the @FailsWithInstantExecution rule

and more ci feedback

also make @IgnoreWithInstantExecution require a reason from a fixed set

and add it to the remaining ignores

Signed-off-by: Paul Merlin <paul@gradle.com>

    • -2
    • +0
    ./DependencyUnresolvedModuleIntegrationTest.groovy
  1. … 126 more files in changeset.
Annotate integ tests failing with instant execution in various projects

after first round of CI feedback

Signed-off-by: Paul Merlin <paul@gradle.com>

    • -0
    • +2
    ./DependencyUnresolvedModuleIntegrationTest.groovy
  1. … 58 more files in changeset.
Annotate integ tests failing with instant execution in :dependencyManagement

Signed-off-by: Paul Merlin <paul@gradle.com>

    • -0
    • +7
    ./DependencyUnresolvedModuleIntegrationTest.groovy
  1. … 93 more files in changeset.
Align implementations of artifact identifier display names

DefaultModuleComponentArtifactIdentifier now behaves similar as

ComponentFileArtifactIdentifier (showing the full actual file name).

This means that the artifact name used during reporting now

contains the version at the usual position in the file name.

This way it shows the actual file name for artifacts originating

from pom-only maven repositories (except snapshots, which show the

SNAPSHOT placeholder) and ivy repositories with default pattern.

The motivation for this alignment is to get the same representation for

the same file, independent of whether it was sourced from traditional

or Gradle module metadata.

    • -3
    • +3
    ./DependencyUnresolvedModuleIntegrationTest.groovy
  1. … 32 more files in changeset.
Restrict cases where to do HTTP retries

This commit restricts the number of cases where we're going to perform HTTP retries. Instead of any error,

we will now retry when:

- a connection timeout occurs (client or server)

- the server responds an error code between 500 and 600

- response code is a too many requests error

Fixes #7850

    • -3
    • +11
    ./DependencyUnresolvedModuleIntegrationTest.groovy
  1. … 4 more files in changeset.
Increase default timeout to 60 seconds in AbstractHttpDependencyResolutionTest (#5212)

Before 4.3, Gradle didn't set timeout for underlying HttpClient,

which used default value (system default). Gradle 4.3 introduced

default timeout 30s, which resulted in lots of flaky tests (localhost

read timeout). Now we try to increase this value to 60s.

Also see https://github.com/gradle/gradle-private/issues/1192

    • -1
    • +3
    ./DependencyUnresolvedModuleIntegrationTest.groovy
  1. … 7 more files in changeset.
Gradle should fail resolution from subsequent repositories on critical errors (#3412)

    • -9
    • +32
    ./DependencyUnresolvedModuleIntegrationTest.groovy
  1. … 15 more files in changeset.
Only abort repository lookups on critical resolution failure

Gradle 4.3 introduced an improvement where an error in resolving a module from

one repository would prevent Gradle from searching for that same module in

subsequent repositories (see #2853).

However, the change to abort searching repositories on _all_ unrecognised errors

proved to be too aggressive. With this change, only repository timeout errors

will prevent Gradle from searching for a module in a subsequent repository.

These timeout errors are considered 'critical' and will blacklist the repository

and abort resolution for that module.

In a future release of Gradle, it is likely that we will expand the set of resolution

failures that we consider 'critical' to include server errors (HTTP 500) and the

like. This commit keeps the set small to miminize impact on the 4.3.1 release.

    • -11
    • +21
    ./DependencyUnresolvedModuleIntegrationTest.groovy
  1. … 9 more files in changeset.
Add integration test coverage for repository blacklisting on timeout

    • -18
    • +55
    ./DependencyUnresolvedModuleIntegrationTest.groovy
Ignore flaky test (#3375)

Ignore flaky test for now

    • -0
    • +1
    ./DependencyUnresolvedModuleIntegrationTest.groovy
Ignore flaky test for now (#3365)

    • -0
    • +2
    ./DependencyUnresolvedModuleIntegrationTest.groovy
Minus 1 when submit `max-workers` to thread pool (#3281)

Fix https://github.com/gradle/gradle/issues/3273

Currently, we allow main thread (i.e. the thread which is waiting for build operation queue's completion)

to execute some work. The consequence is, the actual worker number is max-workers number +1. Since we

can't set --max-workers=0 via command line, that means the work would always be executed parallelly.

This commit only submit `max-workers`-1 threads to thread pool to avoid this issue.

* Remove @Ignore of DependencyUnresolvedModuleIntegrationTest

We fixed the possible issue with `max-workers` (see #3273),

this commit removes @Ignore in DependencyUnresolvedModuleIntegrationTest

    • -3
    • +0
    ./DependencyUnresolvedModuleIntegrationTest.groovy
  1. … 1 more file in changeset.
Ignore two flaky tests temporarily (#3151)

    • -0
    • +3
    ./DependencyUnresolvedModuleIntegrationTest.groovy
Add blacklister to repository management (#3047)

Fix https://github.com/gradle/gradle/issues/2853

Previous versions of Gradle would fall through to the next repository

if resolution in one repository failed. This may cause potentially

indeterministic resolution result. This PR changes this behaviour

and will explicitly rethrow exceptions which occur in dependency

resolution instead of quietly continue to the next repository.

What's more, this PR introduces a RepositoryBlacklister. Exceptions

thrown during dependency resolution are categoried as follows:

1. Caused by HTTP error status code (other than 2xx/3xx/404)

These exceptions would be considered as "recoverable" since

the server seems still to be able to respond.

2. Caused by other IOException/UncheckedIOException

These exceptions would be considered as "unrecoverable"

and the repository would be blacklisted in the build.

    • -0
    • +355
    ./DependencyUnresolvedModuleIntegrationTest.groovy
  1. … 19 more files in changeset.