Gradle

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Fix tests

Restore use of dir name, deduped, for nested build trees

Update test

Fix included build path naming and tests

  1. … 3 more files in changeset.
Make paths/names of included builds immutable

  1. … 18 more files in changeset.
Bump ci-health plugin to 0.71

Bump ci-health plugin to 0.71

Update released version to latest snapshot

Update version to 6.2

Clean accepted API changes

Publish 6.0-20191009230042+0000

Do not expect an exact number of HEAD requests

This seems to be dependent on timing. If one request starts after

another did already finish, it can take the result from cache.

Do not expect an exact number of HEAD requests

This seems to be dependent on timing. If one request starts after

another did already finish, it can take the result from cache.

Do not expect an exact number of HEAD requests

This seems to be dependent on timing. If one request starts after

another did already finish, it can take the result from cache.

Do not expect an exact number of HEAD requests

This seems to be dependent on timing. If one request starts after

another did already finish, it can take the result from cache.

Remove unused imports

Remove unused imports

Remove unused imports

Remove unused imports

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.

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.

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.

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.

Use the first found dependency artifact for override metadata

Later in the resolution, we already combine all artifacts defined

as 'dependency artifacts' on incoming edges.

If a component does not have metadata, we need at least information

about one artifact early when we look for an artifact (instead of a

metadata file).

Use the first found dependency artifact for override metadata

Later in the resolution, we already combine all artifacts defined

as 'dependency artifacts' on incoming edges.

If a component does not have metadata, we need at least information

about one artifact early when we look for an artifact (instead of a

metadata file).

Use the first found dependency artifact for override metadata

Later in the resolution, we already combine all artifacts defined

as 'dependency artifacts' on incoming edges.

If a component does not have metadata, we need at least information

about one artifact early when we look for an artifact (instead of a

metadata file).

Use the first found dependency artifact for override metadata

Later in the resolution, we already combine all artifacts defined

as 'dependency artifacts' on incoming edges.

If a component does not have metadata, we need at least information

about one artifact early when we look for an artifact (instead of a

metadata file).

Reuse one object for empty ComponentOverrideMetadata

Reuse one object for empty ComponentOverrideMetadata

Reuse one object for empty ComponentOverrideMetadata