Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Ivy Test Fixtures: add support for excludes at configuration level

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

  1. … 4 more files in changeset.
Make lock file location configurable

When using the unique lock file per project, it is possible to configure

the lockfile name and location.

This enables scenarios where the lockfile name depends on some build

properties, allowing to have different lock state for different state of

the build.

Issue #11881

  1. … 10 more files in changeset.
Add test coverage for per project lockfile

This is done by making sure most tests cover both the existing file

format and the upcoming file format.

Issue #11881

  1. … 14 more files in changeset.
Add workaround for groovy-2.5.10 switch compilation regression

https://issues.apache.org/jira/browse/GROOVY-9424

Use stream API for loading unique lock file data

Clean up some internal APIs and state in addition and increase test

coverage.

Issue #11881

  1. … 8 more files in changeset.
Initial support for unique lockfile creation

When the feature preview is activated, Gradle will generate a single

lockfile per project when creating or updating lock state.

Issue #11881

  1. … 8 more files in changeset.
Initial support for unique lockfile per project

With a feature preview, Gradle now supports reading from a unique

lockfile per project.

If the support is enabled and the unique lockfile has no lock

information for a locked configuration, Gradle attempts to read the

configuration specific lockfile in case it exists.

Issue #11881

  1. … 9 more files in changeset.
Rename test methods and fixtures

Given that a new format will be introduced for dependency lock files,

the existing methods have legacy in their name for clear identification.

  1. … 11 more files in changeset.
Serialize more details of the project hierachy to the instant execution cache, so that each project's project directory is correct.

Also correctly recreate the project hierarchy. Previously some projects would not be connected to their parent project.

  1. … 18 more files in changeset.
Make sure containers are always shutdown

This commit adds a safety net in case someone forgets to close a container:

a default timeout of 2 minutes would make it happen. If, for some reason,

the code under test takes more time, the timeout can be adjusted.

Add test showing we can keep-alive daemons in containers

  1. … 1 more file in changeset.
Add test case for read-only cache with containers

This commit introduces a test case to check that it's actually

possible to run concurrent docker containers using the same

shared, read-only, dependency cache. It acts both as a test

case and documentation, as mounting the cache as a read-only

volume in Docker is the recommended behavior.

    • -0
    • +84
    ./org/gradle/containers/GradleContainer.groovy
    • -0
    • +79
    ./org/gradle/containers/GradleContainerExecuter.groovy
    • -0
    • +28
    ./org/gradle/containers/GradleExecResult.groovy
    • -0
    • +107
    ./org/gradle/containers/GradleInContainer.groovy
  1. … 15 more files in changeset.
Re-annotate some tests still leaking file handles

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

De-skip tests that don't leak files anymore

but still fail with instant execution

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

  1. … 18 more files in changeset.
Rename @ToBeFixedForInstantExecution.value to skip for explicitness

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

  1. … 36 more files in changeset.
Go over all @ToBeFixedForInstantExecution(Skip.FAILS_IN_SUBCLASS) cases

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

  1. … 14 more files in changeset.
Fix the serialization of `ArtifactCollection` instances that contain the output of artifact transforms to the instant execution cache.

Use a similar strategy to that used to capture the contents of a `FileCollection` that contains the output of artifact transforms.

  1. … 7 more files in changeset.
Do not fail when writing an artifact transform that takes the upstream dependencies of the artifact to the instant execution cache.

In this change, the result will be incorrect because an empty set of dependencies is passed to the transform action when it is loaded from the cache.

  1. … 9 more files in changeset.
Serialize the parameters of an artifact transform to the instant execution cache, rather than attempting to isolate the parameters and then serializing the result.

This allows the parameters to include files and other inputs that may need to be built before they can be queried, for example when the output of some transform is used as an input parameter to another transform (which is something different to chaining of several transforms to produce an output). An implication of this change is that the artifact parameter isolation now happens every time the cache is reused, whereas previously the isolation happened once on write. This can be improved later.

  1. … 11 more files in changeset.
Add API to disable dependency verification

This commit adds an API to disable verification on a specific

configuration (using `resolutionStrategy.disableDependencyVerification`.

This would let tasks which perform special dependency resolution (like

checking newer versions of dependencies) to pass even if dependency

verification is enabled.

  1. … 11 more files in changeset.
Add an XML schema for the verification file

  1. … 4 more files in changeset.
Allow signature verification file generation

This commit adds the ability to generate a verification file which relies

on PGP signature verification. With this mode, Gradle will download the

signatures and verify them. Depending on the result of verification,

Gradle will either:

- automatically add trusted keys if verification passed

- automatically ignore keys if they couldn't be downloaded

- automatically ignore keys if verification failed

If verification failed or that a key couldn't be downloaded, a

WARNING will be issued to encourage the user to verify what

happened.

In order to reduce the size of the verification file, Gradle will

also automatically perform "normalization" of verifications by

configuring globally trusted keys for artifacts which share the same

group or a common super group.

  1. … 22 more files in changeset.
Add ability to ignore keys for a specific artifact

The use case for this is whenever signature for an artifact fails, but

for some reason the user still trusts the artifact. For example, a POM

file is different between different repositories because it happened

to be published twice with different timestamps.

In this case it is recommended to ignore the signature, however we

_will_ fallback on checksum verification.

  1. … 13 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. … 12 more files in changeset.
Add support for globally trusted keys

A globally trusted key can be used to trust a number of

modules and greatly simplifies configuration: instead of

having to specify checksums for all modules, a user can

declare the keys they trust and use a similar syntax to

trusted artifacts to say to what group/name/version the

key applies.

It's often the case that the same keys are used for

several artifacts of the same group or same company, so

this makes it possible to avoid a lot of boilerplate as

long as the artifacts are signed by the same keys.

  1. … 9 more files in changeset.
Add support for ignored keys

Ignored keys can be used in case verification of a signature isn't

possible because a key isn't available anymore (lost, not published

to a key server, ...).

It's worth noting that if a component cannot be verified by at least

one public key, then verification will fallback to checksum verification.

  1. … 17 more files in changeset.
Make sure we can verify artifacts downloaded in a previous build

  1. … 3 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.
Allow a build services to be used as the parameter for isolated objects, such as other build services, artifact transforms or worker API actions.

There are still some missing pieces to this:

- Worker classloader and process isolation is not supported.

- Services are stopped in the order they are created, rather than in reverse dependency order.

- Parallel usage constraints specified for these services are not honoured.

  1. … 17 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.

  1. … 3 more files in changeset.