[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #1046 was SUCCESSFUL (with 2456 tests)
--- Spring Data GemFire > Nightly-ApacheGeode > #1046 was successful. --- Scheduled 2458 tests in total. https://build.spring.io/browse/SGF-NAG-1046/ -- This message is automatically generated by Atlassian Bamboo
Re: [DISCUSS] test code style (particularly logging)
For simple single threaded tests System.out would do the job. For a multi-threaded test I have found the logging framework to be helpful because of the thread id and the timestamps. On Thu, Sep 20, 2018 at 1:50 PM Dale Emery wrote: > As long as the stdout is available in the test results, I’m more than > happy to avoid coupling the tests to the product logging code. > > > On Sep 20, 2018, at 1:39 PM, Galen O'Sullivan > wrote: > > > > I was reviewing a PR recently and noticed that we have some test code > that > > uses Logger (or LogWriter). If I understand correctly, anything logged to > > stdout will be included in the test output, and anything logged in a > DUnit > > VM will be logged with the appropriate VM number prepended in the output. > > Because logging is coupled to product code, I propose we log all test > > output to standard out (using System.out.println or such). I also propose > > we add this to the Geode style guide. > > > > Thoughts/questions/objections? > > > > Thanks, > > Galen > > > — > Dale Emery > dem...@pivotal.io > >
Re: [DISCUSS] test code style (particularly logging)
As long as the stdout is available in the test results, I’m more than happy to avoid coupling the tests to the product logging code. > On Sep 20, 2018, at 1:39 PM, Galen O'Sullivan wrote: > > I was reviewing a PR recently and noticed that we have some test code that > uses Logger (or LogWriter). If I understand correctly, anything logged to > stdout will be included in the test output, and anything logged in a DUnit > VM will be logged with the appropriate VM number prepended in the output. > Because logging is coupled to product code, I propose we log all test > output to standard out (using System.out.println or such). I also propose > we add this to the Geode style guide. > > Thoughts/questions/objections? > > Thanks, > Galen — Dale Emery dem...@pivotal.io
[DISCUSS] test code style (particularly logging)
I was reviewing a PR recently and noticed that we have some test code that uses Logger (or LogWriter). If I understand correctly, anything logged to stdout will be included in the test output, and anything logged in a DUnit VM will be logged with the appropriate VM number prepended in the output. Because logging is coupled to product code, I propose we log all test output to standard out (using System.out.println or such). I also propose we add this to the Geode style guide. Thoughts/questions/objections? Thanks, Galen
Requesting Access to Concourse
Hi, I would like to have admin access to Concourse at https://concourse.apachegeode-ci.info/ so that I can help maintain the pipelines. Thanks, Galen
concourse environment recreation
Unfortunately due to some fat fingering on my part, the concourse deployment was destroyed. We are in the process of recreating it. The impact of this is that build logs/history is gone, but artifacts are still present. Any jobs that were running at the time are gone. Pipelines will need to be redeployed. ETA end of day. -Sean.
Extension Service - life cycle?
What's the recommended way to define an external service? Is there a set of interfaces that define life-cycle for an extension? I see CacheService[1] but it is currently defined as internal. [1] https://raw.githubusercontent.com/apache/geode/880a9d614d1ac2418c5bace4fdbb8e255ab8e3dd/geode-core/src/main/java/org/apache/geode/internal/cache/CacheService.java
