I merged some new AcceptanceTests to develop after having my PR go GREEN.
But now these tests are failing in Windows.
I'd like to propose that we add the Windows jobs to our PR checks if we
plan to keep testing on Windows in CI.
Please vote or discuss.
Thanks,
Kirk
+1 for adding all JDK11 Windows tests to PR pipeline.
On 6/25/20, 9:29 AM, "Kirk Lund" wrote:
I merged some new AcceptanceTests to develop after having my PR go GREEN.
But now these tests are failing in Windows.
I'd like to propose that we add the Windows jobs to our PR checks if w
+1
-Original Message-
From: Owen Nichols
Sent: Thursday, June 25, 2020 9:38 AM
To: dev@geode.apache.org
Subject: Re: [PROPOSAL] Add windows jobs to PR checks
+1 for adding all JDK11 Windows tests to PR pipeline.
On 6/25/20, 9:29 AM, "Kirk Lund" wrote:
I merged some new Acceptanc
+1, what was the reason for it not being included the PR before?
From: Dick Cavender
Sent: Thursday, June 25, 2020 9:54 AM
To: dev@geode.apache.org
Subject: RE: [PROPOSAL] Add windows jobs to PR checks
+1
-Original Message-
From: Owen Nichols
Sent: Thur
+1 to add Windows jobs to PR checks (1)
I know there are some folks who may be resistant to this for good reasons,
but the problem is that what we are currently doing is untenable and
wasteful. Every other week, I hit this and then waste a day reverting,
fixing, resubmitting.
I don't want to subm
> On Jun 25, 2020, at 10:01 AM, Jinmei Liao wrote:
>
> +1, what was the reason for it not being included the PR before?
The Windows integration and acceptance tests take a very long time to run
because we can’t dockerize and parallelize them. They have also be very flaky
in the past.
+1
I recently ran into some Windows failures related to test ordering and
Integration tests not properly cleaning up after themselves (totally unrelated
to my changes) after merging a PR. If the PR checks had shown these failures,
the underlying issue could have been addressed before merging my
Another option:
(5) introduce a new staging branch that PRs merge directly to. Windows
testing occurs on this staging branch. Then any PRs that pass on the
staging branch can then be merged or cherry-picked to develop.
On Thu, Jun 25, 2020 at 10:08 AM Jacob Barrett wrote:
>
>
> > On Jun 25, 202
This is going to hurt timewise, but +1.
> On Jun 25, 2020, at 10:11 AM, Kirk Lund wrote:
>
> Another option:
>
> (5) introduce a new staging branch that PRs merge directly to. Windows
> testing occurs on this staging branch. Then any PRs that pass on the
> staging branch can then be merged or c
If they take a very long time to run, how about adding them but not requiring
them to pass?
On 6/25/20, 10:08 AM, "Jacob Barrett" wrote:
> On Jun 25, 2020, at 10:01 AM, Jinmei Liao wrote:
>
> +1, what was the reason for it not being included the PR before?
The Windows inte
In principal, +1 for adding them.
But if it is gating or not, is determined by how much extra time we now have to
add to waiting for a PR build to complete.
Is there any way that we could improve the time testing time of these?
—Udo
On Jun 25, 2020, 11:05 AM -0700, Bruce Schuchardt , wrote:
If
+1 to add Windows tests to the PR pipeline. It may take longer time to run
(up to 4 hours). But consider the time wasted on reverting, fixing and
resubmitting, if there is a failure after merging to the develop branch. It
is better to add the Windows tests to the PR pipeline. We can reevaluate
and
I support adding it in, but I think the time wasted is less than you think. I
think for me the most important thing is finding an issue when it is put in.
I think the current way is actually faster and more efficient, because every PR
doesn’t have to wait the 4 hours and in reality the number is
It's been a couple of years since Sai and I tried (but failed) to dockerize the
tests. I'm sure docker support has improved and it might be worth trying that
again.
--Jens
On 6/25/20, 10:08 AM, "Jacob Barrett" wrote:
> On Jun 25, 2020, at 10:01 AM, Jinmei Liao wrote:
>
> +1,
> On Jun 25, 2020, at 12:23 PM, Jens Deppe wrote:
> It's been a couple of years since Sai and I tried (but failed) to dockerize
> the tests. I'm sure docker support has improved and it might be worth trying
> that again.
Docker on windows has improved a lot but wasn’t the major issue the docke
Looking at the cost and value derived; My vote is with current/existing process
(not running for every PR).
On 6/25/20, 11:39 AM, "Mark Hanson" wrote:
I support adding it in, but I think the time wasted is less than you think.
I think for me the most important thing is finding an issue wh
I'm attempting to do a build on a Windows machine against develop HEAD:
*C:\Users\kirkl\dev\geode>gradlew.bat build -x test*
This exact machine was able to build Geode in the past. It now generates 3
errors saying it cannot do a GET for 3 resources.
All 3 are com.google dependencies, and the bui
After a couple attempts, this started working... so go figure! Nevermind.
If anyone else sees this just try again.
On Thu, Jun 25, 2020 at 2:34 PM Kirk Lund wrote:
> I'm attempting to do a build on a Windows machine against develop HEAD:
>
> *C:\Users\kirkl\dev\geode>gradlew.bat build -x test*
In case anyone is interested in the developer experience building with unit
tests on windows:
It succeeds (after a couple tries) but something in geode-wan:test spits
out a partial stack trace. Since all the tests passed, I don't really see a
way to find out which test generated it.
C:\Users\kirk
PS: This is develop HEAD on Windows 10. It used to build and run unit tests
cleanly on this machine but I don't do this very often.
On Thu, Jun 25, 2020 at 2:53 PM Kirk Lund wrote:
> In case anyone is interested in the developer experience building with
> unit tests on windows:
>
> It succeeds (
How about another option:
6) Provide someway to file a secondary/optional Pull Request that just runs
the Windows tests. This 2nd PR would never go anywhere (just get closed
after reviewing the test results) and it could even be on a fork of Apache
Geode to keep it from polluting the main PR secti
I vote to is also with current/existing process (not running for every PR).
We can create an on-request prechecking running on windows machine like what we
did for running some regression tests, if someone really need to run it on
windows (Actually, I'd love to have this tool)
On 6/25/20, 1:52
Hi Kirk,
I build on Ubuntu 18.02 and I occasionally see the partial stack traces you
mentioned on geode-wan:tests you mentioned. So it is not just a Windows thing.
Never figured out what they provoked them and neither how to get them
consistently.
BR,
Alberto
23 matches
Mail list logo
