+1 for the naming convention of *Test, *IntegrationTest, and
*DistributedTest. It鈥檚 mostly personal preference, but I also agree with
Kirk鈥檚 comment that it makes it easier to find the test you are looking for
by file name. I also find it easier to see the test type I鈥檓 working with
in the file t
+1
The release will be a great one with so many historical bugs fixed.
Today I tried to use IJ to build and run with latest build.gradle and
recent moved test packages, it worked. So this refactoring is also success.
On Tue, Aug 21, 2018 at 3:52 PM, Anthony Baker wrote:
> I most definitely agr
Looks like it's a feature:
https://github.com/google/google-java-format/issues/62
Is it too late to down-vote our use of google-java-format?
On Tue, Aug 21, 2018 at 3:43 PM, Kirk Lund wrote:
> I suppose I was using that older format of the Apache license header and
> then using spotlessApply 10
If not late, I would also like to include GEODE-5594 (enabling hostname
verification)
and GEODE-5338 (using the default SSL context) into 1.7.0.
PRs for both are open and currently up for review.
On Tue, Aug 21, 2018 at 2:26 PM Dan Smith wrote:
> I think we do want to wait for GEODE-5615 (Distr
---
Spring Data GemFire > Nightly-ApacheGeode > #1016 was successful.
---
Scheduled
2425 tests in total.
https://build.spring.io/browse/SGF-NAG-1016/
--
Thi
I most definitely agree!
Anthony
> On Aug 21, 2018, at 2:26 PM, Dan Smith wrote:
>
> I think we do want to wait for GEODE-5615 (DistributedTest OOMEs) and
> GEODE-5601 (AcceptanceTest port conflicts) to be fixed before cutting the
> new 1.7 branch. It would be better if we don't create a relea
I suppose I was using that older format of the Apache license header and
then using spotlessApply 100% before running spotlessCheck which was
reformatting the license header. So even though I was using the older one,
I never ran into the problem until today.
So maybe nothing changed?
But, I still
I know it's not a bug in spotless. I think we now have the settings a bit
too strict.
As of 2-3 weeks ago, I was able to follow the "Setting up IntelliJ" process
that I documented at https://github.com/gemfire/gemfire (search down
for "Setting
up IntelliJ") without spotless failing. See the format
Ken and I are paired up to containerize now.
> On Aug 21, 2018, at 2:20 PM, Dan Smith wrote:
>
> I see we have a few JIRAs that were filed related to this issue. I think I
> cleaned them up, so whoever is working on fixing you can use this JIRA -
> https://issues.apache.org/jira/browse/GEODE-560
The only addition with respect to spotless on the 10th was to add the
`devBuild` target (which runs `spotlessApply`) and to require that
`spotlessApply` would run before `compileJava`, if both were to run in a
given build command.
Looking at the PR against which these failed, it looks like it migh
I think we do want to wait for GEODE-5615 (DistributedTest OOMEs) and
GEODE-5601 (AcceptanceTest port conflicts) to be fixed before cutting the
new 1.7 branch. It would be better if we don't create a release branch from
a point where we have these systematic issues with our pipeline.
-Dan
On Tue,
I see we have a few JIRAs that were filed related to this issue. I think I
cleaned them up, so whoever is working on fixing you can use this JIRA -
https://issues.apache.org/jira/browse/GEODE-5601.
Until this is fixed, let's not create new JIRAs for AcceptanceTest failures.
-Dan
On Tue, Aug 21,
=
The build job for Apache Geode version 1.8.0-build.1313 has failed.
Build artifacts are available at:
http://files.apachegeode-ci.info/builds/1.8.0-build.1313/geode-build-artifacts-1.8.0-build.1313.
Until docker on docker is supported for acceptance tests you can disable
the parallelism on forks with -DdunitParallelForks=1 when running
acceptanceTest. We can do the same in the CI for now too. :(
The change for the CI can be found in
ci/pipelines/shared/variablesomething.yml.
-Jake
On Tue,
I will wait for a day to give all developers sometime to commit any new
fixes into develop that is needed in 1.7.0. Please do let me know if there
is any concern.
Regards
Nabarun Nag
On Tue, Aug 21, 2018 at 12:42 PM Nabarun Nag wrote:
> Yeah , I can continue with the release manager tasks. My
Yeah , I can continue with the release manager tasks. My understanding from
Dan's email is that every JIRA that was closed as 1.8 needs to be changed
to 1.7 after we rebase develop over release/1.7 branch.
Regards
Nabarun Nag
On Tue, Aug 21, 2018 at 11:57 AM Dan Smith wrote:
> +1 to updating t
Imagine if all the dunits and integration tests were named FooTest and now
you finally want to write a unit test for Foo. You'll need to create a 3rd
test named FootTest or rename the existing FooTests to FooIntegrationTest
or FooDistributedTest. Since we have separate source sets for all three,
na
+1 to updating the 1.7 branch.
There is also a 1.8 version in JIRA, and I think a bunch of things are
marked as resolved in 1.8. So if you update the release branch you should
probably update the fixed version on all these issues.
-Dan
On Tue, Aug 21, 2018 at 11:39 AM, Alexander Murmann
wrote:
Are there any benefits of naming them specifically to reflect the category?
I am used to look at test category annotation to differentiate a test is a
single-vm or a multi-vm.
On Tue, Aug 21, 2018 at 11:29 AM Anthony Baker wrote:
> The original purpose of specific names was because we filtered t
I looked through the gradle files and couldn't figure out where to make the
changes. If anyone else knows, please make the changes or let me know if
you want to pair with me so I can learn.
On Tue, Aug 21, 2018 at 11:32 AM, Anthony Baker wrote:
> By design, acceptanceTest should be run with defa
Hi everyone!
We cut this release branch 3 months ago and then the release got stalled.
Since then we鈥檝e added another 432 commits to develop. We also have 83
resolved Jira tickets marked as 1.8 and another 91 Jira tickets that are
labeled as 1.7, but were resolved after the 1.7 branch was cut 馃檮.
There was already an open discussion about how to name tests recently on
the dev list, and the (newish) content about "Writing tests" on the Wiki
reflects what the group wanted at that time. I think everyone in this
community needs to be more active on the dev list in the future, especially
anyone
Yeah +0 from me for the same reason.
I鈥檇 just make them all *Test. Let the grouping speak for itself.
> On Aug 21, 2018, at 11:28 AM, Anthony Baker wrote:
>
> The original purpose of specific names was because we filtered test execution
> based on the name pattern (then we switched to categori
By design, acceptanceTest should be run with defaults (including ports). So if
they aren鈥檛 run in containers they can鈥檛 be run in parallel.
Anthony
> On Aug 21, 2018, at 11:15 AM, Kirk Lund wrote:
>
> Oops... I mean "orphaned processes"
>
> On Tue, Aug 21, 2018 at 11:13 AM, Kirk Lund wrote
The original purpose of specific names was because we filtered test execution
based on the name pattern (then we switched to categories and now we use source
sets / dirs).
I like the idea of changing *JUnitTest to *Test. I鈥檓 not as excited about
*IntegrationTest and friends. But I鈥檓 willing t
Oops... I mean "orphaned processes"
On Tue, Aug 21, 2018 at 11:13 AM, Kirk Lund wrote:
> So, we need to disable running them in parallel and improve the tearDown
> to make sure these tests don't leave an orphaned tests behind.
>
> On Tue, Aug 21, 2018 at 11:11 AM, Sai Boorlagadda <
> sai.boorlag
So, we need to disable running them in parallel and improve the tearDown to
make sure these tests don't leave an orphaned tests behind.
On Tue, Aug 21, 2018 at 11:11 AM, Sai Boorlagadda wrote:
> jdbc-connector acceptance tests need docker-in-docker (also docker-compose)
> to spin up mysql and po
jdbc-connector acceptance tests need docker-in-docker (also docker-compose)
to spin up mysql and postgres.
On Tue, Aug 21, 2018 at 11:04 AM Dan Smith wrote:
> Actually, it looks like the problem is that we are *not* using docker
> containers for the acceptance tests. Check this out, in
> gradle/
The acceptance tests used to run fine in parallel in the same host. We need
docker in docker working to containerize them. We would need to add docker to
the docker image and some other fun stuff. Short term you can make the tests
run serially. :(
-Jake
> On Aug 21, 2018, at 11:04 AM, Dan Smi
A good rule of thumb is to never test with default ports unless the test
runs in a container. Otherwise, running tests in parallel will fail
miserably.
On Tue, Aug 21, 2018 at 10:44 AM, Kirk Lund wrote:
> GEODE-5590 would seem to imply that GfshRule does not have an adequate
> safe guard? If it
Actually, it looks like the problem is that we are *not* using docker
containers for the acceptance tests. Check this out, in
gradle/docker.gradle. Since acceptance tests use the default port, this
means the test are guaranteed to be flaky, especially since we are running
them in parallel:
//A
> On Aug 21, 2018, at 10:44 AM, Kirk Lund wrote:
>
> GEODE-5590 would seem to imply that GfshRule does not have an adequate safe
> guard? If it spawns a server process which binds to the default server port
> and that process persists after the test then we need better tearDown.
>
Yes, that d
GEODE-5590 would seem to imply that GfshRule does not have an adequate safe
guard? If it spawns a server process which binds to the default server port
and that process persists after the test then we need better tearDown.
Actually I thought we were using Docker to run each AcceptanceTest in
isola
GEODE-5590 was opened recently for these tests that have started failing with
BindExceptions on the default server port.
> On Aug 21, 2018, at 10:27 AM, Kirk Lund wrote:
>
> Oh yeah, I see it now! I forgot how to read that page. Thanks!
>
> On Tue, Aug 21, 2018 at 10:18 AM, Sai Boorlagadda > w
Recently all of the AcceptanceTest failures I've looked at have been around
bind exceptions on startup which implies test pollution from prior tests.
--Jens
On Tue, Aug 21, 2018 at 10:18 AM Sai Boorlagadda
wrote:
> The metrics job themselves will be green (as they complete to success) but
> you
Oh yeah, I see it now! I forgot how to read that page. Thanks!
On Tue, Aug 21, 2018 at 10:18 AM, Sai Boorlagadda wrote:
> The metrics job themselves will be green (as they complete to success) but
> you can expand the get_metrics task output and see that build#20 started
> reporting these failur
DeployWithLargeJarTest & PutCommandWithJsonTest are flaky on Develop.
DeployWithLargeJarTest -
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/335
PutCommandWithJsonTest -
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/Acceptan
The metrics job themselves will be green (as they complete to success) but
you can expand the get_metrics task output and see that build#20 started
reporting these failures, so probably these are due to recent changes on
develop. I believe these metrics are from develop CI test runs.
On Tue, Aug 2
Those metrics show AcceptanceTests consistently GREEN. Do these metrics
include test failures from pull request precheckin runs like mine? Or does
it just cover CI test runs?
On Tue, Aug 21, 2018 at 10:09 AM, Sai Boorlagadda wrote:
> Metrics show these started failing recently.
>
> https://conco
+1 Yes! This naming scheme matches what we already have on the Apache Geode
Wiki [1] for naming tests.
Side note: Looks like we need to update the pages on the Wiki to match our
recent changes involving JUnit categories.
[1] https://cwiki.apache.org/confluence/display/GEODE/Writing+tests
On Tue,
Metrics show these started failing recently.
https://concourse.apachegeode-ci.info/teams/main/pipelines/metrics/jobs/GeodeAcceptanceTestMetrics/builds/20
On Tue, Aug 21, 2018 at 10:07 AM Kirk Lund wrote:
> Are PutCommandWithJsonTest and DeployWithLargeJarTest known to be flaky?
>
> My latest pu
Are PutCommandWithJsonTest and DeployWithLargeJarTest known to be flaky?
My latest pull request failed with these two failures and all I did was
extract LocalRegion.validateRegionName and improve unit testing of
RegionNameValidation. No other tests failed for me.
> Task :geode-assembly:acceptance
Many tests file names are *JUnitTest.java[1] even though it is an
integration test or distributed test. After we segregated into respective
folders and removed the test category it is not visible which test it is
unless we look back into the path of the source directory (integrationTest
or distribu
This appears to be caused by changes made to the build around August 10?
On Tue, Aug 21, 2018 at 9:38 AM, Kirk Lund wrote:
> Why is spotless now complaining about correct English? By correct English,
> I mean having 2 spaces between sentences in javadoc or comments (in this
> case it's the Apach
Why is spotless now complaining about correct English? By correct English,
I mean having 2 spaces between sentences in javadoc or comments (in this
case it's the Apache license header):
-路*路the路License.路路You路may路obtain路a路copy路of路the路License路at
+路*路the路License.路You路may路obtain路a路copy路of路the路License路
45 matches
Mail list logo
