demery-pivotal opened a new pull request #6280:
URL: https://github.com/apache/geode/pull/6280


   Updated Geode's build system to use Gradle 6.8.3:
   
   - Updated the gradle wrapper to use Gradle 6.8.3.
   - Updated geode-assembly/build.gradle to make the ivy "repository"
     compatible with Gradle 6.8.3.
   - Changed ./gradle.properties to specify 'minimumGradleVersion=6.8'.
   - Updated the expected-pom.xml file to the format that Gradle 6.8.3
     produces.
   - Updated all Gradle plugins to the latest versions.
   - In buildSrc/build.gradle, added groovy source sets for testing, to
     allow running tests of plugin code.
   - Updated common "test isolation" code to be compatible with Gradle
     6.8.3. See below for details.
   - Updated the RepeatTest task to be compatible with Gradle 6.8.3. See
     below for details.
   - Rewrote the Dockerized test plugin to be compatible with Gradle 6.8.3.
     See below for details.
   - Added a new 'dunitDockerJVM' project property to allow developers run
     tests in Docker on macOS. To do this, use -PtestJVM to identify the
     mac's JVM, and use -PdunitDockerJVM to specify the JVM for the test
     worker process running in Docker.
   - Updated the BUILDING.md file for Gradle 6.8.3. As part of this I added
     two versions of the Apache copyright notice to the etc dir: A plain
     text version and an xml version that IntelliJ IDEA can import into its
     copyright settings.
   
   ===== Test isolation code =====
   
   Some code for isolating tests is used by the RepeatTest task and the
   Dockerized test plugin. This code was updated to be compatible with
   Gradle v6.8.3, and to somewhat reduce its dependence on Gradle internal
   implementation details:
   
   - WorkingDirectoryIsolator adjusts a given ProcessBuilder to give it a
     unique working directory.
   - AdjustableProcessLauncher applies a given Consumer (such as the
     isolator, above) to adjust each ProcessBuilder before launching the
     process.
   - LauncherProxyWorkerProcessBuilder and
     LauncherProcessWorkerProcessFactory forcefully update each Gradle exec
     handle to use a given ProcessLauncher to launch test worker processes.
   - Executers and Workers offer convenience methods for constructing
     TestExecuters and ProcessWorker builders and factories.
   
   ===== RepeatTest task update =====
   
   Geode's RepeatTest task uses a custom TestExecuter that was copied from
   Gradle 5.5 (or earlier) and modified. This custom class is now updated
   to be compatible with Gradle 6.8.3, and renamed from
   OverriddenTestExecutor to RepeatableTestExecuter.
   
   ===== Dockerized test plugin rewrite =====
   
   Removed the modified copy of pedjak's Dockerized test plugin.
   
   Configuration
   -------------
   
   - Rewrote gradle/docker.gradle and renamed it as
     gradle/multi-process-test.gradle.
   - Moved the code that translates project properties into configuration
     settings from the plugin to the config class. Renamed the config class
     as DockerTestWorkerConfig.
   - Moved code that configures command lines and environments for Docker
     test workers based on project properties. Thise code was defiend as a
     closure in a build script. It is now a method in
     DockerTestWorkerConfig.
   - Changed command line options that CI scripts pass to Gradle to run
     tests in Docker:
       - Specify the --max-workers Gradle option to configure the maximum
         number of workers.
       - Specify the 'testMaxParallelForks' project property to configure
         the maximum number of forks for each test task.
       - Remove the 'dunitParallelForks' option.
   
   Implementation
   --------------
   
   The Dockerized test plugin uses these classes to launches processes in
   Docker containers:
   
   - DockerProcess overrides java.lang.Process to represent a test worker
     process running in Docker.
   - DockerProcessLauncher launches each test worker process in a Docker
     container, and creates a DockerProcess to represent and manage it.
   - Other classes described in the "Test isolation code" section, above.
   
   The plugin overrides several of Gradle's internal classes to allow test
   worker processes running in Docker containers to communicate with
   Gradle:
   
   - DockerConnectionAcceptor implements Gradle's ConnectionAcceptor, which
     (among other responsibilities), produces a "multi-choice address" that
     a test worker process can use to connect to Gradle's messaging server.
     Gradle's default implementation produces multi-choice addresses that
     processes in Docker containers cannot use.
   - DockerMessagingServer implements Gradle's MessagingServer using
     DockerConnectionAcceotpr.
   - WildcardBindingInetAddressFactory overrides Gradle's
     InetAddressFactory to instruct messaging servers to listen on an
     address that processes in Dockerized containers can connect to.
   
   Timeouts
   --------
   
   Due to a recent surge of CI problems due to delays in Docker operations,
   I rewrote the plugins's timeout mechanism to make it configurable and
   much more robust:
   
   - Added a 'dockerTimeout' project property, defaulting to 5 minutes.
     Each Docker operation will throw an exception if its duration exceeds
     this value.
   - Log a warning if any Docker operation takes longer than 1 minute. This
     can help us to see how often significant delays occur in CI, while
     still allowing tests to proceed.
   - These exceptions and warnings identify the project for which test
     worker process is being launched. This can help us to see whether
     there are project-specific factors that affect the delays.
   
   Thank you for submitting a contribution to Apache Geode.
   
   In order to streamline the review of the contribution we ask you
   to ensure the following steps have been taken:
   
   ### For all changes:
   - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?
   
   - [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?
   
   - [ ] Is your initial contribution a single, squashed commit?
   
   - [ ] Does `gradlew build` run cleanly?
   
   - [ ] Have you written or updated unit tests to verify your changes?
   
   - [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
   
   ### Note:
   Please ensure that once the PR is submitted, check Concourse for build 
issues and
   submit an update to your PR as soon as possible. If you need help, please 
send an
   email to [email protected].
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
[email protected]


Reply via email to