Re: Next release: 1.4.0

+1 It should be pretty easy to clone the current pipeline for the 1.4.0 release branch. I’ll plan to update the Jenkins jobs to run the `build` and `updateArchives` tasks since those still have value. Anthony > On Jan 4, 2018, at 5:03 PM, Alexander Murmann wrote: > >

Re: Next release: 1.4.0

The release pipeline is up: https://concourse.apachegeode-ci.info/teams/main/pipelines/release-1.4.0 -Sean. On Fri, Jan 5, 2018 at 10:00 AM, Anthony Baker wrote: > +1 > > It should be pretty easy to clone the current pipeline for the 1.4.0 > release branch. > > I’ll plan to

Broken: apache/geode#5423 (develop - bb9ae49)

Build Update for apache/geode - Build: #5423 Status: Broken Duration: 12 minutes and 22 seconds Commit: bb9ae49 (develop) Author: Bruce Schuchardt Message: GEODE-4229 CI failure due to suspect string: "Locator socket was closed unexpectedly" Removing

Re: Next release: 1.4.0

Hi Anil, Thanks, I'll take a look at that, I added that test a little while ago.. On Fri, Jan 5, 2018 at 10:13 AM Anilkumar Gingade wrote: > I see :rat failing on Jenkins... > > The last run: https://builds.apache.org/job/Geode-release/100/console > > All test reports at >

Build failed in Jenkins: Geode-release #100

See -- [...truncated 172.58 KB...] :geode-common:processTestResources NO-SOURCE :geode-common:testClasses :geode-common:checkMissedTests :geode-common:spotlessJavaCheck

Re: Next release: 1.4.0

I see :rat failing on Jenkins... The last run: https://builds.apache.org/job/Geode-release/100/console All test reports at /home/jenkins/jenkins-slave/workspace/Geode-release/build/reports/combined FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':rat'. >

Geode unit tests completed in 'develop/FlakyTest' with non-zero exit code

Pipeline results can be found at: Concourse: https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/FlakyTest/builds/91

Build failed in Jenkins: Geode-nightly #1065

See Changes: [bschuchardt] GEODE-4229 CI failure due to suspect string: "Locator socket was closed [nabarunnag] GEODE-4135: Awaitility condition added [metatype] Fix script so passing.txt is branch-dependent.

Handling files and user.dir in tests

Any calls such as: File file = new File("myfile"); ...results in creating a file in the current working directory of IntelliJ or Gradle when executing the test. I previously made a change to Gfsh so that tests can pass in a parent directory which will be used instead. This allowed me to

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #788 was SUCCESSFUL (with 2324 tests)

--- Spring Data GemFire > Nightly-ApacheGeode > #788 was successful. --- Scheduled 2326 tests in total. https://build.spring.io/browse/SGF-NAG-788/ -- This

Geode unit tests completed in 'develop/AcceptanceTest' with non-zero exit code

Pipeline results can be found at: Concourse: https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/110

Build failed in Jenkins: Geode-release-flaky #49

See -- [...truncated 143.51 KB...] :geode-assembly:docs :geode-assembly:gfshDepsJar :geode-client-protocol:javadoc :geode-client-protocol:javadocJar :geode-client-protocol:sourcesJar

Re: Next release: 1.4.0

I'm fine with switching off of Jenkins, we just need to be clear on what our release criteria will be. It sounds like the new criteria being proposed is that the concourse pipeline is passing for the release. -Dan On Thu, Jan 4, 2018 at 5:03 PM, Alexander Murmann wrote: >

Re: Next release: 1.4.0

I need to merge feature/GEODE-4192 to the release branch.  There is a Protobuf client/locator change that needs to be included in the release. On 1/5/18 11:15 AM, Sean Goller wrote: The release pipeline is up: https://concourse.apachegeode-ci.info/teams/main/pipelines/release-1.4.0 -Sean.

Geode unit tests completed in 'develop/FlakyTest' with non-zero exit code

Pipeline results can be found at: Concourse: https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/FlakyTest/builds/93

Geode unit tests completed in 'develop/AcceptanceTest' with non-zero exit code

Pipeline results can be found at: Concourse: https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/113

Build failed in Jenkins: Geode-nightly-flaky #205

See Changes: [dschneider] GEODE-4161: fix gfsh describe jdbc-mapping [github] GEODE-4191: Replace imports of io.codearte..Mockito with [github] GEODE-4193: fix password file security in JMX (#1227) [github]

Re: Handling files and user.dir in tests

Just to help facilitate the discussion, here's a pull request that changes GMSLocator from: this.viewFile = new File(System.getProperty("user.dir"), "locator" + server.getPort() + "view.dat"); ...to: this.viewFile = new File(System.getProperty("user.dir"), "locator" + server.getPort() +

Geode unit tests completed in 'release-1.4.0/IntegrationTest' with non-zero exit code

Pipeline results can be found at: Concourse: https://concourse.apachegeode-ci.info/teams/main/pipelines/release-1.4.0/jobs/IntegrationTest/builds/1

Geode unit tests completed in 'develop/AcceptanceTest' with non-zero exit code

Pipeline results can be found at: Concourse: https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/112

Errored: apache/geode#5433 (release/1.4.0 - 21d243d)

Build Update for apache/geode - Build: #5433 Status: Errored Duration: 34 minutes and 19 seconds Commit: 21d243d (release/1.4.0) Author: jinmeiliao Message: GEODE-4131: add the deprecated API in MemberMXBean (#1231) (cherry picked from commit 78438f8) View

Jenkins build is back to normal : Geode-nightly #1066

See

Re: Next release: 1.4.0

I’ve updated the Jenkins nightly and release jobs. Please ping me if you have any questions. Anthony > On Jan 5, 2018, at 10:00 AM, Anthony Baker wrote: > > +1 > > It should be pretty easy to clone the current pipeline for the 1.4.0 release > branch. > > I’ll plan to

[DISCUSS] Benchmarks module package structure

Team, I am in the progress of adding new benchmarks to the (currently sparse) geode-benchmarks module. The lack of current examples in the module leads me to wonder what the correct organization of benchmarks in the module is (and if this is the right location). The existing benchmarks are all