Clone Tools
  • last updated a few minutes ago
Constraints: committers
Constraints: files
Constraints: dates
Add Gradle API metadata jar to the `testRuntime`

Fix build logic to work with -Dorg.gradle.internal.tasks.eager=true

by simplifying extension/tasks properties,

removing Provider<FileCollection> and Provider<FileTree> properties

for the purpose of the eager vs. lazy performance comparison test

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

  1. … 1 more file in changeset.
Get samples tests running again

Commit dc49f73c2d37a3d36feb72244f980ea5fca34ddc excluded sample

config and output from the distributions, but also the integ test

distribution, which caused UserGuideSamplesIntegrationTest to

find 0 samples to test.

This change ensures that the samples are included for integ testing

but not in the real -all distribution.

Also fixes 3 samples tests that had broken in the meantime.

  1. … 4 more files in changeset.
Let the distributions contain a gradle-api-metadata jar

which contains resources defining the Gradle API

- includes/excludes declaring the API packages

- API members parameter names absent from Java 7 bytecode

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

  1. … 3 more files in changeset.
Improve laziness of gradlebuild by using build scans

  1. … 16 more files in changeset.
Convert all remaining task creation to lazy configuration

  1. … 25 more files in changeset.
Handle distributions:intTestImage without removing the jar task

  1. … 1 more file in changeset.
Use configureEach over configureEachLater

configureEachLater is going to be removed.

  1. … 12 more files in changeset.
Add `:distributions:uploadDistributionSnapshot` task

To replace the TC artifactory publish plugin in the publication of the

Kotlin DSL distribution wrappers.

Avoid configuring Test tasks

  1. … 8 more files in changeset.
Make a bunch of shit lazy

  1. … 14 more files in changeset.
Moved publicApi script to buildSrc/configuration and polish

- Removed extra property usage for public api includes/excludes

- Added missing gradlebuild prefix to jmh and cleanup plugin

  1. … 9 more files in changeset.
Introduced the property moduleType to derive source compatibility settings

  1. … 80 more files in changeset.
Removed almost all extra properties and extracted build environment check into plugin

- Moved extra properties into extension methods

- Created AddVerifyProductionEnvironmentTaskPlugin

- Moved build-extensions from kotlin-dsl to configuration submodule

- Created separate extensions for project groups

  1. … 38 more files in changeset.
Extracted test file cleanup from root build into plugin

- Moved configuration of test file clean into extension

- Added TestFileCleanUpPlugin

- Moved CiReporting and Classycle plugin into codequality module

  1. … 23 more files in changeset.
Fixed srcDist tasks to include the new buildSrc structure

Keep properties close to Provider classes

  1. … 8 more files in changeset.
Import constraints in more subprojects

see 7e922ba

  1. … 1 more file in changeset.
Include buildSrc/gradle.properties in source distribution

Convert `settings.gradle` to the Kotlin DSL (#3790)

- `apply { from(...) }` already resolves paths against `settingsDir`

- Clarify project directory name derivation from project name

- Include `*.gradle.kts` files in source distribution

  1. … 2 more files in changeset.
Include `released-versions.json` in src distribution

Remove incoming distribution concept

  1. … 5 more files in changeset.
Remove incoming distribution concept

  1. … 5 more files in changeset.
Make use of the `japicmp` plugin to check for binary compatibility

This commit introduces the use of the JApiCmp plugin to check for binary compatibility between releases of Gradle.

The binary compatibility checks now generate a report per project, based on the last release version. Accepted

changes need to be added to the `distributions/src/changes/changes-since-x.y.txt` file.

- The build will fail if a non accepted, binary breaking change, is introduced.

- Removes the binary breaking change test as it is superceded by the plugin use

- Uses a single binary compatibility check task for all projects, which aggregates classpath

This commit addresses a concern with regards to refactoring between modules. With individual reports, some errors would occur because

we moved classes from one module to the other, while, in practice, all are shipped together (as of now). This means that you cannot,

in practice, consider all artifacts as separate. They form a whole which is "the Gradle API", for good or for bad.

The custom rules:

- automatically accept changes based on our `@Incubating` policy

- make sure that all rules declared in `changes-since.txt` are matched

This plugins adds a sanity check, making sure that all the regressions that we declare

as accepted in the `changes-since` file actually match a rule. If not, the build will

fail, requiring to review this file.

Binary compatibility checks is executed as part of `sanityCheck` and `check`.

  1. … 14 more files in changeset.
Test binary compatibility on each commit

We add a test which checks if the public API of the current version is

binary compatible to the last released version.

Currently, this test lives in `distributions` until it has found a

better home. We could also run this test as part of sanity check since

it is pretty fast (6s).

The public API definition has been extracted to the root build script.

It could be nice to have the definition in a place where the test

could easily load it without going through using system properties.

  1. … 4 more files in changeset.
Remove test exclusions

We need to revisit which exclusions can be make sense.

  1. … 2 more files in changeset.
Switch forked integration tests to run with daemon by default

  1. … 16 more files in changeset.
Increase memory for the daemon

The Gradle build needs more than 1G for some more demanding tasks

like a parallel `quickCheck`.

This change also reduces the client VM memory to something reasonable.

It was set to 2G before because we were running the build in the client

VM on CI. Instead we will now be forking single-use daemons on CI, which

only adds ~500ms per build and interoperates better with the memory being

defined in gradle.properties.

  1. … 9 more files in changeset.
Lazily evaluate the reference to the createBuildReceipt task

  1. … 1 more file in changeset.
Remove version-info.jar

+review REVIEW-6527

  1. … 13 more files in changeset.