Build Lucene.NET :: Lucene.NET Core [master] #431 failed (Tests failed: 9 (6
new), passed: 2444, ignored: 112).
Agent: JetBrains-dotnet-agent01
Build results:
http://teamcity.codebetter.com/viewLog.html?buildId=191292buildTypeId=LuceneNet_Core
Failed Tests Summary:
Newly failed tests (6 tests,
GitHub user laimis opened a pull request:
https://github.com/apache/lucenenet/pull/145
use Environment.TickCount instead DateTime.Now.Millisecond
During the port System.currentTimeMillis was translated to
System.DateTime.Now.Millisecond which are not equivalent. This introduced
Github user laimis commented on the pull request:
https://github.com/apache/lucenenet/pull/145#issuecomment-102659773
Also removed LongRunningTest or Ignore attributes on the tests that used to
fail because of this before.
---
If your project is set up for it, you can reply to this
Github user synhershko commented on the pull request:
https://github.com/apache/lucenenet/pull/145#issuecomment-102659785
Can you rebase please? :)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not
On Sat, May 16, 2015 at 3:22 PM Wyatt Barnett wyatt.barn...@gmail.com
wrote:
I agree with Itamar -- it feels environmental. I'll do some digging into
the teamcity output but I think the plan of setting up some extra verbose
logging here would make sense. I can set you up with a separate build
There are three tests that consistently fail on TC but no matter how many
times I try, I can't reproduce it locally. These tests are:
TestFuzzyQuery.TestTieBreaker
Yes, that would be the best way to do this. On Java Lucene, the randomized
tests framework allows you to re-use the random seed associated with the
failure, but we are not there yet. Either way, I suspect this to be an
environment issue rather than a code path one.
--
Itamar Syn-Hershko
Sorry about the blank one -- getting used to google inbox here and I
misclicked.
Anyhow, I have a repro or at least a rhyme and reason -- TeamCity is
running in release mode and I think we have difffering behavior there. If
you switch your copy of visual studio to release mode you will get the
Github user laimis commented on the pull request:
https://github.com/apache/lucenenet/pull/145#issuecomment-102660198
@synhershko can you check now? If it is too messy I can reopen a different
PR, ot sure if I did this right
---
If your project is set up for it, you can reply to
Build Lucene.NET :: Lucene.NET Core [master] #434 failed (Tests failed: 6 (1
new), passed: 2456, ignored: 107).
Agent: JetBrains-dotnet-agent01
Build results:
http://teamcity.codebetter.com/viewLog.html?buildId=191298buildTypeId=LuceneNet_Core
Failed Tests Summary:
Newly failed tests (1 test,
Wyatt,
Sweet, I will let you know once I have a branch out with additional logging
and separate category for tests that you can configure to run.
Re: release mode, tried that and was able to fix a few bugs after switching
to it. They were in that PR with debug.assert changes. Who knows, the
GitHub user laimis opened a pull request:
https://github.com/apache/lucenenet/pull/143
use setup/teardown instead of fixture setup/teardown
Lucene41.TestBlockPostingsFormat2 teardown is failing because the cleanup
is not run after each test. Instead it is run after all test cases
Github user synhershko commented on a diff in the pull request:
https://github.com/apache/lucenenet/pull/145#discussion_r30463210
--- Diff: src/Lucene.Net.Core/Util/OfflineSorter.cs ---
@@ -34,486 +34,6 @@ namespace Lucene.Net.Util
/// /summary
public sealed class
Github user laimis commented on a diff in the pull request:
https://github.com/apache/lucenenet/pull/145#discussion_r30463250
--- Diff: src/Lucene.Net.Core/Util/OfflineSorter.cs ---
@@ -34,486 +34,6 @@ namespace Lucene.Net.Util
/// /summary
public sealed class
GitHub user laimis opened a pull request:
https://github.com/apache/lucenenet/pull/144
Incrementtoken fixes
Couple more places where incrementtoken was not sealed.
Also match target platform for release builds to what is set in debug
builds. This was preventing tests to
Github user laimis commented on the pull request:
https://github.com/apache/lucenenet/pull/145#issuecomment-102663771
@synhershko oh yeah, you are right, I will keep that in mind.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub
Github user asfgit closed the pull request at:
https://github.com/apache/lucenenet/pull/144
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
Github user asfgit closed the pull request at:
https://github.com/apache/lucenenet/pull/143
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
I agree with Itamar -- it feels environmental. I'll do some digging into
the teamcity output but I think the plan of setting up some extra verbose
logging here would make sense. I can set you up with a separate build
pointed at your fork if that helps -- it will keep the feedback cycle
tighter.
Github user synhershko commented on the pull request:
https://github.com/apache/lucenenet/pull/145#issuecomment-102662514
Good catch, I'll merge now.
For the record, `DateTime.UtcNow.Ticks` is a closer equivalent to
`System.currentTimeMillis` but for the purpose of this
Sounds good Laimis. You will need to setup a login to the CodeBetter
teamcity server and get added to the lucene.net group if you haven't
already. Let me know if you need help there too.
On Sat, May 16, 2015 at 4:52 PM Laimonas Simutis lai...@gmail.com wrote:
Wyatt,
Sweet, I will let you know
21 matches
Mail list logo
