You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Kirk Lund <kl...@apache.org> on 2020/06/25 16:29:42 UTC
[PROPOSAL] Add windows jobs to PR checks
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
Re: [PROPOSAL] Add windows jobs to PR checks
Posted by Kirk Lund <kl...@apache.org>.
+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 submit more PRs with tests until this is actually resolved
because I'm sick of this problem.
In order of my preferences:
1) add Windows jobs to PR checks
2) remove Windows jobs from CI if we don't test them in PR (I *NEVER* want
to see a *GREEN* PR that then breaks CI)
3) add some new complicated process in which we manually or automatically
trigger Windows jobs against a PR *BEFORE* we consider merging it to develop
4) stop writing new tests or editing existing tests that might fail on
Windows
Thanks,
Kirk
On Thu, Jun 25, 2020 at 9:29 AM Kirk Lund <kl...@apache.org> 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 we
> plan to keep testing on Windows in CI.
>
> Please vote or discuss.
>
> Thanks,
> Kirk
>
Re: [PROPOSAL] Add windows jobs to PR checks
Posted by Owen Nichols <on...@vmware.com>.
Requesting Windows checks on an individual PR is now as simple as adding a "windows" label.
Labels can be added in GitHub (just below the list of reviewers). The best time to add this is when creating the PR (if adding this label to an existing PR, you'll need to push another commit or an empty commit before it will "see" the new label).
A huge thanks to new committer @sabbey37 for making this possible!
On 6/25/20, 3:51 PM, "Kirk Lund" <kl...@apache.org> wrote:
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 section for Apache Geode.
Submitting this Windows PR would be optional and I would probably only
submit certain kinds of changes or tests to run on the Windows tests.
On Thu, Jun 25, 2020 at 1:51 PM Anilkumar Gingade <ag...@vmware.com>
wrote:
> 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" <mh...@pivotal.io> 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 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 of
> windows failures is lower than the number of linux failures.
>
> Just a thought.
>
> Thanks,
> Mark
>
>
> > On Jun 25, 2020, at 11:30 AM, Jianxia Chen <jc...@apache.org>
> wrote:
> >
> > +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 optimize the pipeline if the long running time is truly a
> concern.
> >
> > On Thu, Jun 25, 2020 at 9:29 AM Kirk Lund <kl...@apache.org> 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 we
> >> plan to keep testing on Windows in CI.
> >>
> >> Please vote or discuss.
> >>
> >> Thanks,
> >> Kirk
> >>
>
>
>
Re: [PROPOSAL] Add windows jobs to PR checks
Posted by Kirk Lund <kl...@apache.org>.
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 section for Apache Geode.
Submitting this Windows PR would be optional and I would probably only
submit certain kinds of changes or tests to run on the Windows tests.
On Thu, Jun 25, 2020 at 1:51 PM Anilkumar Gingade <ag...@vmware.com>
wrote:
> 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" <mh...@pivotal.io> 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 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 of
> windows failures is lower than the number of linux failures.
>
> Just a thought.
>
> Thanks,
> Mark
>
>
> > On Jun 25, 2020, at 11:30 AM, Jianxia Chen <jc...@apache.org>
> wrote:
> >
> > +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 optimize the pipeline if the long running time is truly a
> concern.
> >
> > On Thu, Jun 25, 2020 at 9:29 AM Kirk Lund <kl...@apache.org> 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 we
> >> plan to keep testing on Windows in CI.
> >>
> >> Please vote or discuss.
> >>
> >> Thanks,
> >> Kirk
> >>
>
>
>
Re: [PROPOSAL] Add windows jobs to PR checks
Posted by Xiaojian Zhou <zh...@vmware.com>.
What I am looking for is a script like following:
./regression -Z <aws instance size - default i3.2xlarge, but please use i3.large whenever possible> deploy \
-n <number of instances> \
-o <Operating system - default centos7> \
-g <path to a GemFire build TAR file> \
-u <your username for correlation in hydradb - required> \
-t <your teamname for display by regression tools: optional - no default> \
-k <public ssh key generated by you to access instances once they are launched (id_rsa.pub).> \
-F <path to local functional test file for upload: optional> \
<regression-name used to uniquely identify your regression>
Example:
./regression deploy -n 10 -o centos7 \
-g ~/gemfire/closed/pivotalgf-assembly/build/distributions/pivotal-gemfire-regression-0.0.0.tgz \
-k ~/.ssh/id_rsa.pub -u johndoe -t storageteam myregression
```
Operating systems to choose from are:
* centos7
* rhel7
* ubuntu14*
* ubuntu16*
* sles12*
* sles11*
* windows
^^^^^^^^^ ------------>
We use to have a
script call "precheckin". I forgot if we can select operating system like above "regression" script.
On 6/25/20, 4:09 PM, "Xiaojian Zhou" <zh...@vmware.com> wrote:
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 PM, "Anilkumar Gingade" <ag...@vmware.com> wrote:
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" <mh...@pivotal.io> 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 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 of windows failures is lower than the number of linux failures.
Just a thought.
Thanks,
Mark
> On Jun 25, 2020, at 11:30 AM, Jianxia Chen <jc...@apache.org> wrote:
>
> +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 optimize the pipeline if the long running time is truly a concern.
>
> On Thu, Jun 25, 2020 at 9:29 AM Kirk Lund <kl...@apache.org> 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 we
>> plan to keep testing on Windows in CI.
>>
>> Please vote or discuss.
>>
>> Thanks,
>> Kirk
>>
Re: [PROPOSAL] Add windows jobs to PR checks
Posted by Xiaojian Zhou <zh...@vmware.com>.
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 PM, "Anilkumar Gingade" <ag...@vmware.com> wrote:
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" <mh...@pivotal.io> 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 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 of windows failures is lower than the number of linux failures.
Just a thought.
Thanks,
Mark
> On Jun 25, 2020, at 11:30 AM, Jianxia Chen <jc...@apache.org> wrote:
>
> +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 optimize the pipeline if the long running time is truly a concern.
>
> On Thu, Jun 25, 2020 at 9:29 AM Kirk Lund <kl...@apache.org> 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 we
>> plan to keep testing on Windows in CI.
>>
>> Please vote or discuss.
>>
>> Thanks,
>> Kirk
>>
Re: [PROPOSAL] Add windows jobs to PR checks
Posted by Anilkumar Gingade <ag...@vmware.com>.
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" <mh...@pivotal.io> 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 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 of windows failures is lower than the number of linux failures.
Just a thought.
Thanks,
Mark
> On Jun 25, 2020, at 11:30 AM, Jianxia Chen <jc...@apache.org> wrote:
>
> +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 optimize the pipeline if the long running time is truly a concern.
>
> On Thu, Jun 25, 2020 at 9:29 AM Kirk Lund <kl...@apache.org> 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 we
>> plan to keep testing on Windows in CI.
>>
>> Please vote or discuss.
>>
>> Thanks,
>> Kirk
>>
Re: [PROPOSAL] Add windows jobs to PR checks
Posted by Mark Hanson <mh...@pivotal.io>.
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 of windows failures is lower than the number of linux failures.
Just a thought.
Thanks,
Mark
> On Jun 25, 2020, at 11:30 AM, Jianxia Chen <jc...@apache.org> wrote:
>
> +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 optimize the pipeline if the long running time is truly a concern.
>
> On Thu, Jun 25, 2020 at 9:29 AM Kirk Lund <kl...@apache.org> 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 we
>> plan to keep testing on Windows in CI.
>>
>> Please vote or discuss.
>>
>> Thanks,
>> Kirk
>>
Re: [PROPOSAL] Add windows jobs to PR checks
Posted by Jianxia Chen <jc...@apache.org>.
+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 optimize the pipeline if the long running time is truly a concern.
On Thu, Jun 25, 2020 at 9:29 AM Kirk Lund <kl...@apache.org> 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 we
> plan to keep testing on Windows in CI.
>
> Please vote or discuss.
>
> Thanks,
> Kirk
>
Re: [PROPOSAL] Add windows jobs to PR checks
Posted by Donal Evans <do...@vmware.com>.
+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 changes and avoided the need to revert.
________________________________
From: Jinmei Liao <ji...@vmware.com>
Sent: Thursday, June 25, 2020 10:01 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [PROPOSAL] Add windows jobs to PR checks
+1, what was the reason for it not being included the PR before?
________________________________
From: Dick Cavender <di...@vmware.com>
Sent: Thursday, June 25, 2020 9:54 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: RE: [PROPOSAL] Add windows jobs to PR checks
+1
-----Original Message-----
From: Owen Nichols <on...@vmware.com>
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" <kl...@apache.org> 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 we
plan to keep testing on Windows in CI.
Please vote or discuss.
Thanks,
Kirk
Re: Docker on Windows
Posted by Jacob Barrett <ja...@vmware.com>.
Rebase complete and draft PR is open. I see the same null pointer issue Dale reported. Its a problem with the crufty Gradle Docker plugin we are using. It is the very reason we were thinking about making this move towards JUnit 5.
Here is what I think for next steps.
1) Disable test parallelization via Gradle Docker plugin.
2) Stabilize any other test issues.
3) Migrate to new Gradle runner for parallelization.
-Jake
On Jun 29, 2020, at 11:06 AM, Dale Emery <de...@vmware.com>> wrote:
• CI failures on JDK 11
• NPE thrown apparently by Gradle
Re: Docker on Windows
Posted by Jacob Barrett <ja...@vmware.com>.
On Jun 29, 2020, at 11:20 AM, Robert Houghton <rh...@vmware.com>> wrote:
@Jacob Barrett<ma...@vmware.com> @Dale Emery<ma...@vmware.com> I am excited to see progress on this. What I do not know, is what Junit5 buys us in terms of test isolation and parallelism compared to what we have now.
Based on Jen’s comment regarding fixing the docker plugin we use to launch JUnit tests in isolation.
On Jun 26, 2020, at 11:13 AM, Jens Deppe <jd...@vmware.com>> wrote:
A bigger effort (but I think more correct and sustainable) would be to switch to junit 5 where something like this could more easily be implemented.
Re: Docker on Windows
Posted by Robert Houghton <rh...@vmware.com>.
@Jacob Barrett<ma...@vmware.com> @Dale Emery<ma...@vmware.com> I am excited to see progress on this. What I do not know, is what Junit5 buys us in terms of test isolation and parallelism compared to what we have now.
From: Jacob Barrett <ja...@vmware.com>
Date: Monday, June 29, 2020 at 11:16 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Docker on Windows
Awesome! I will take a quick stab at rebasing the changes and see if anything has improved.
I will figure out a good place to setup a shared branch for collaboration.
-Jake
On Jun 29, 2020, at 11:06 AM, Dale Emery <de...@vmware.com>> wrote:
Here are my notes from my most recent attempts:
• November
• Added JUnit 5 to geode-junit API
• Configured geode-junit and geode-core to run all tests via JUnit 5
• CI failures on JDK 11
• NPE thrown apparently by Gradle
• December
• Ran tests in JDK 11 on my Mac
• Failures do not occur on my Mac
• Set gradle’s log level to info
• Results in CI logs so enormous that Chrome cannot display them in a bearable timeframe
• Then the whole PR CI pipeline became unusable
• So I was able to gain no further information about the cause of the gradle NPEs
Here is the branch the way I left things: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdemery-pivotal%2Fgeode%2Ftree%2Fold%2Fgeode-junit5&data=02%7C01%7Crhoughton%40vmware.com%7C09249e9ba58844c7563308d81c588743%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637290513849574069&sdata=fPzImBwZ2zivCSdP6mPCGBFQNrpaahQuhZNpP3I4%2BIY%3D&reserved=0
About the PR CI pipeline becoming unusable… I don’t have any notes about what “unusable” means. I suspect it was unrelated to my PR, but I’m not sure.
Cheers,
Dale
On Jun 29, 2020, at 10:51 AM, Jacob Barrett <ja...@vmware.com>> wrote:
Dale,
Sorry I thought it was Kirk. Do you have a branch somewhere with your work so far? Can you refresh us all on the issues you hit and what you think the next steps would be?
Thanks,
Jake
On Jun 29, 2020, at 10:23 AM, Kirk Lund <kl...@apache.org>> wrote:
It was Dale who worked on migrating Geode to use JUnit 5. I know he ran
into some issues but I don't recall what they were. I'm definitely up for
helping on the JUnit 5 front!
On Fri, Jun 26, 2020 at 11:30 AM Jacob Barrett <ja...@vmware.com>> wrote:
If the effort to do both is less than the sum of each individually then I
say lets do it.
Kirk, I recall you putting some effort into JUnit 5 at some point.
-Jake
On Jun 26, 2020, at 11:13 AM, Jens Deppe <jd...@vmware.com>> wrote:
A bigger effort (but I think more correct and sustainable) would be to
switch to junit 5 where something like this could more easily be
implemented.
--Jens
On 6/26/20, 9:11 AM, "Robert Houghton" <rh...@vmware.com>> wrote:
The plugin code that spawns junit test workers on containers needs
some serious help. Aside from the benefit we would get on windows, we also
are blocked on getting to the next major version of Gradle with the current
tool. I really think it might be easier to write our own Gradle plugin at
this point.
From: Jacob Barrett <ja...@vmware.com>>
Date: Thursday, June 25, 2020 at 12:26 PM
To: dev@geode.apache.org<ma...@geode.apache.org> <de...@geode.apache.org>>
Subject: Docker on Windows
On Jun 25, 2020, at 12:23 PM, Jens Deppe <jd...@vmware.com>> 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
docker plugin for Gradle needed some serious work?
I have recently been experimenting with the Docker/Kubernetes for
Windows experience. Perhaps we can take another stab at this issue.
-Jake
—
Dale Emery
demery@vmware.com<ma...@vmware.com>>
Re: Docker on Windows
Posted by Jacob Barrett <ja...@vmware.com>.
Awesome! I will take a quick stab at rebasing the changes and see if anything has improved.
I will figure out a good place to setup a shared branch for collaboration.
-Jake
On Jun 29, 2020, at 11:06 AM, Dale Emery <de...@vmware.com>> wrote:
Here are my notes from my most recent attempts:
• November
• Added JUnit 5 to geode-junit API
• Configured geode-junit and geode-core to run all tests via JUnit 5
• CI failures on JDK 11
• NPE thrown apparently by Gradle
• December
• Ran tests in JDK 11 on my Mac
• Failures do not occur on my Mac
• Set gradle’s log level to info
• Results in CI logs so enormous that Chrome cannot display them in a bearable timeframe
• Then the whole PR CI pipeline became unusable
• So I was able to gain no further information about the cause of the gradle NPEs
Here is the branch the way I left things: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdemery-pivotal%2Fgeode%2Ftree%2Fold%2Fgeode-junit5&data=02%7C01%7Cjabarrett%40vmware.com%7C1d35ce2b861a4caf5a4f08d81c574bc4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637290508574727794&sdata=jTQbw4pKbcxwnUJ%2B3RC%2BvUOiyqHU5Xtro8Xg0D4vnFo%3D&reserved=0
About the PR CI pipeline becoming unusable… I don’t have any notes about what “unusable” means. I suspect it was unrelated to my PR, but I’m not sure.
Cheers,
Dale
On Jun 29, 2020, at 10:51 AM, Jacob Barrett <ja...@vmware.com>> wrote:
Dale,
Sorry I thought it was Kirk. Do you have a branch somewhere with your work so far? Can you refresh us all on the issues you hit and what you think the next steps would be?
Thanks,
Jake
On Jun 29, 2020, at 10:23 AM, Kirk Lund <kl...@apache.org>> wrote:
It was Dale who worked on migrating Geode to use JUnit 5. I know he ran
into some issues but I don't recall what they were. I'm definitely up for
helping on the JUnit 5 front!
On Fri, Jun 26, 2020 at 11:30 AM Jacob Barrett <ja...@vmware.com>> wrote:
If the effort to do both is less than the sum of each individually then I
say lets do it.
Kirk, I recall you putting some effort into JUnit 5 at some point.
-Jake
On Jun 26, 2020, at 11:13 AM, Jens Deppe <jd...@vmware.com>> wrote:
A bigger effort (but I think more correct and sustainable) would be to
switch to junit 5 where something like this could more easily be
implemented.
--Jens
On 6/26/20, 9:11 AM, "Robert Houghton" <rh...@vmware.com>> wrote:
The plugin code that spawns junit test workers on containers needs
some serious help. Aside from the benefit we would get on windows, we also
are blocked on getting to the next major version of Gradle with the current
tool. I really think it might be easier to write our own Gradle plugin at
this point.
From: Jacob Barrett <ja...@vmware.com>>
Date: Thursday, June 25, 2020 at 12:26 PM
To: dev@geode.apache.org<ma...@geode.apache.org> <de...@geode.apache.org>>
Subject: Docker on Windows
On Jun 25, 2020, at 12:23 PM, Jens Deppe <jd...@vmware.com>> 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
docker plugin for Gradle needed some serious work?
I have recently been experimenting with the Docker/Kubernetes for
Windows experience. Perhaps we can take another stab at this issue.
-Jake
—
Dale Emery
demery@vmware.com<ma...@vmware.com>
Re: Docker on Windows
Posted by Dale Emery <de...@vmware.com>.
Here are my notes from my most recent attempts:
• November
• Added JUnit 5 to geode-junit API
• Configured geode-junit and geode-core to run all tests via JUnit 5
• CI failures on JDK 11
• NPE thrown apparently by Gradle
• December
• Ran tests in JDK 11 on my Mac
• Failures do not occur on my Mac
• Set gradle’s log level to info
• Results in CI logs so enormous that Chrome cannot display them in a bearable timeframe
• Then the whole PR CI pipeline became unusable
• So I was able to gain no further information about the cause of the gradle NPEs
Here is the branch the way I left things: https://github.com/demery-pivotal/geode/tree/old/geode-junit5
About the PR CI pipeline becoming unusable… I don’t have any notes about what “unusable” means. I suspect it was unrelated to my PR, but I’m not sure.
Cheers,
Dale
On Jun 29, 2020, at 10:51 AM, Jacob Barrett <ja...@vmware.com>> wrote:
Dale,
Sorry I thought it was Kirk. Do you have a branch somewhere with your work so far? Can you refresh us all on the issues you hit and what you think the next steps would be?
Thanks,
Jake
On Jun 29, 2020, at 10:23 AM, Kirk Lund <kl...@apache.org>> wrote:
It was Dale who worked on migrating Geode to use JUnit 5. I know he ran
into some issues but I don't recall what they were. I'm definitely up for
helping on the JUnit 5 front!
On Fri, Jun 26, 2020 at 11:30 AM Jacob Barrett <ja...@vmware.com>> wrote:
If the effort to do both is less than the sum of each individually then I
say lets do it.
Kirk, I recall you putting some effort into JUnit 5 at some point.
-Jake
On Jun 26, 2020, at 11:13 AM, Jens Deppe <jd...@vmware.com>> wrote:
A bigger effort (but I think more correct and sustainable) would be to
switch to junit 5 where something like this could more easily be
implemented.
--Jens
On 6/26/20, 9:11 AM, "Robert Houghton" <rh...@vmware.com>> wrote:
The plugin code that spawns junit test workers on containers needs
some serious help. Aside from the benefit we would get on windows, we also
are blocked on getting to the next major version of Gradle with the current
tool. I really think it might be easier to write our own Gradle plugin at
this point.
From: Jacob Barrett <ja...@vmware.com>>
Date: Thursday, June 25, 2020 at 12:26 PM
To: dev@geode.apache.org<ma...@geode.apache.org> <de...@geode.apache.org>>
Subject: Docker on Windows
On Jun 25, 2020, at 12:23 PM, Jens Deppe <jd...@vmware.com>> 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
docker plugin for Gradle needed some serious work?
I have recently been experimenting with the Docker/Kubernetes for
Windows experience. Perhaps we can take another stab at this issue.
-Jake
—
Dale Emery
demery@vmware.com<ma...@vmware.com>
Re: Docker on Windows
Posted by Jacob Barrett <ja...@vmware.com>.
Dale,
Sorry I thought it was Kirk. Do you have a branch somewhere with your work so far? Can you refresh us all on the issues you hit and what you think the next steps would be?
Thanks,
Jake
> On Jun 29, 2020, at 10:23 AM, Kirk Lund <kl...@apache.org> wrote:
>
> It was Dale who worked on migrating Geode to use JUnit 5. I know he ran
> into some issues but I don't recall what they were. I'm definitely up for
> helping on the JUnit 5 front!
>
> On Fri, Jun 26, 2020 at 11:30 AM Jacob Barrett <ja...@vmware.com> wrote:
>
>> If the effort to do both is less than the sum of each individually then I
>> say lets do it.
>>
>> Kirk, I recall you putting some effort into JUnit 5 at some point.
>>
>> -Jake
>>
>>
>>> On Jun 26, 2020, at 11:13 AM, Jens Deppe <jd...@vmware.com> wrote:
>>>
>>> A bigger effort (but I think more correct and sustainable) would be to
>> switch to junit 5 where something like this could more easily be
>> implemented.
>>>
>>> --Jens
>>>
>>> On 6/26/20, 9:11 AM, "Robert Houghton" <rh...@vmware.com> wrote:
>>>
>>> The plugin code that spawns junit test workers on containers needs
>> some serious help. Aside from the benefit we would get on windows, we also
>> are blocked on getting to the next major version of Gradle with the current
>> tool. I really think it might be easier to write our own Gradle plugin at
>> this point.
>>>
>>>
>>> From: Jacob Barrett <ja...@vmware.com>
>>> Date: Thursday, June 25, 2020 at 12:26 PM
>>> To: dev@geode.apache.org <de...@geode.apache.org>
>>> Subject: Docker on Windows
>>>
>>>> On Jun 25, 2020, at 12:23 PM, Jens Deppe <jd...@vmware.com> 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
>> docker plugin for Gradle needed some serious work?
>>>
>>> I have recently been experimenting with the Docker/Kubernetes for
>> Windows experience. Perhaps we can take another stab at this issue.
>>>
>>> -Jake
>>>
>>
>>
Re: Docker on Windows
Posted by Kirk Lund <kl...@apache.org>.
It was Dale who worked on migrating Geode to use JUnit 5. I know he ran
into some issues but I don't recall what they were. I'm definitely up for
helping on the JUnit 5 front!
On Fri, Jun 26, 2020 at 11:30 AM Jacob Barrett <ja...@vmware.com> wrote:
> If the effort to do both is less than the sum of each individually then I
> say lets do it.
>
> Kirk, I recall you putting some effort into JUnit 5 at some point.
>
> -Jake
>
>
> > On Jun 26, 2020, at 11:13 AM, Jens Deppe <jd...@vmware.com> wrote:
> >
> > A bigger effort (but I think more correct and sustainable) would be to
> switch to junit 5 where something like this could more easily be
> implemented.
> >
> > --Jens
> >
> > On 6/26/20, 9:11 AM, "Robert Houghton" <rh...@vmware.com> wrote:
> >
> > The plugin code that spawns junit test workers on containers needs
> some serious help. Aside from the benefit we would get on windows, we also
> are blocked on getting to the next major version of Gradle with the current
> tool. I really think it might be easier to write our own Gradle plugin at
> this point.
> >
> >
> > From: Jacob Barrett <ja...@vmware.com>
> > Date: Thursday, June 25, 2020 at 12:26 PM
> > To: dev@geode.apache.org <de...@geode.apache.org>
> > Subject: Docker on Windows
> >
> >> On Jun 25, 2020, at 12:23 PM, Jens Deppe <jd...@vmware.com> 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
> docker plugin for Gradle needed some serious work?
> >
> > I have recently been experimenting with the Docker/Kubernetes for
> Windows experience. Perhaps we can take another stab at this issue.
> >
> > -Jake
> >
>
>
Re: Docker on Windows
Posted by Jacob Barrett <ja...@vmware.com>.
If the effort to do both is less than the sum of each individually then I say lets do it.
Kirk, I recall you putting some effort into JUnit 5 at some point.
-Jake
> On Jun 26, 2020, at 11:13 AM, Jens Deppe <jd...@vmware.com> wrote:
>
> A bigger effort (but I think more correct and sustainable) would be to switch to junit 5 where something like this could more easily be implemented.
>
> --Jens
>
> On 6/26/20, 9:11 AM, "Robert Houghton" <rh...@vmware.com> wrote:
>
> The plugin code that spawns junit test workers on containers needs some serious help. Aside from the benefit we would get on windows, we also are blocked on getting to the next major version of Gradle with the current tool. I really think it might be easier to write our own Gradle plugin at this point.
>
>
> From: Jacob Barrett <ja...@vmware.com>
> Date: Thursday, June 25, 2020 at 12:26 PM
> To: dev@geode.apache.org <de...@geode.apache.org>
> Subject: Docker on Windows
>
>> On Jun 25, 2020, at 12:23 PM, Jens Deppe <jd...@vmware.com> 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 docker plugin for Gradle needed some serious work?
>
> I have recently been experimenting with the Docker/Kubernetes for Windows experience. Perhaps we can take another stab at this issue.
>
> -Jake
>
Re: Docker on Windows
Posted by Jens Deppe <jd...@vmware.com>.
A bigger effort (but I think more correct and sustainable) would be to switch to junit 5 where something like this could more easily be implemented.
--Jens
On 6/26/20, 9:11 AM, "Robert Houghton" <rh...@vmware.com> wrote:
The plugin code that spawns junit test workers on containers needs some serious help. Aside from the benefit we would get on windows, we also are blocked on getting to the next major version of Gradle with the current tool. I really think it might be easier to write our own Gradle plugin at this point.
From: Jacob Barrett <ja...@vmware.com>
Date: Thursday, June 25, 2020 at 12:26 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Docker on Windows
> On Jun 25, 2020, at 12:23 PM, Jens Deppe <jd...@vmware.com> 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 docker plugin for Gradle needed some serious work?
I have recently been experimenting with the Docker/Kubernetes for Windows experience. Perhaps we can take another stab at this issue.
-Jake
Re: Docker on Windows
Posted by Robert Houghton <rh...@vmware.com>.
The plugin code that spawns junit test workers on containers needs some serious help. Aside from the benefit we would get on windows, we also are blocked on getting to the next major version of Gradle with the current tool. I really think it might be easier to write our own Gradle plugin at this point.
From: Jacob Barrett <ja...@vmware.com>
Date: Thursday, June 25, 2020 at 12:26 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Docker on Windows
> On Jun 25, 2020, at 12:23 PM, Jens Deppe <jd...@vmware.com> 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 docker plugin for Gradle needed some serious work?
I have recently been experimenting with the Docker/Kubernetes for Windows experience. Perhaps we can take another stab at this issue.
-Jake
Docker on Windows
Posted by Jacob Barrett <ja...@vmware.com>.
> On Jun 25, 2020, at 12:23 PM, Jens Deppe <jd...@vmware.com> 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 docker plugin for Gradle needed some serious work?
I have recently been experimenting with the Docker/Kubernetes for Windows experience. Perhaps we can take another stab at this issue.
-Jake
Re: [PROPOSAL] Add windows jobs to PR checks
Posted by Jens Deppe <jd...@vmware.com>.
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" <ja...@vmware.com> wrote:
> On Jun 25, 2020, at 10:01 AM, Jinmei Liao <ji...@vmware.com> 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.
Re: [PROPOSAL] Add windows jobs to PR checks
Posted by Mark Hanson <mh...@pivotal.io>.
This is going to hurt timewise, but +1.
> On Jun 25, 2020, at 10:11 AM, Kirk Lund <kl...@apache.org> 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 cherry-picked to develop.
>
> On Thu, Jun 25, 2020 at 10:08 AM Jacob Barrett <ja...@vmware.com> wrote:
>
>>
>>
>>> On Jun 25, 2020, at 10:01 AM, Jinmei Liao <ji...@vmware.com> 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.
>>
>>
Re: [PROPOSAL] Add windows jobs to PR checks
Posted by Kirk Lund <kl...@apache.org>.
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 <ja...@vmware.com> wrote:
>
>
> > On Jun 25, 2020, at 10:01 AM, Jinmei Liao <ji...@vmware.com> 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.
>
>
Re: [PROPOSAL] Add windows jobs to PR checks
Posted by Udo Kohlmeyer <ud...@vmware.com>.
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 <br...@vmware.com>, wrote:
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" <ja...@vmware.com> wrote:
On Jun 25, 2020, at 10:01 AM, Jinmei Liao <ji...@vmware.com> 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.
Re: [PROPOSAL] Add windows jobs to PR checks
Posted by Bruce Schuchardt <br...@vmware.com>.
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" <ja...@vmware.com> wrote:
> On Jun 25, 2020, at 10:01 AM, Jinmei Liao <ji...@vmware.com> 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.
Re: [PROPOSAL] Add windows jobs to PR checks
Posted by Jacob Barrett <ja...@vmware.com>.
> On Jun 25, 2020, at 10:01 AM, Jinmei Liao <ji...@vmware.com> 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.
Re: [PROPOSAL] Add windows jobs to PR checks
Posted by Jinmei Liao <ji...@vmware.com>.
+1, what was the reason for it not being included the PR before?
________________________________
From: Dick Cavender <di...@vmware.com>
Sent: Thursday, June 25, 2020 9:54 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: RE: [PROPOSAL] Add windows jobs to PR checks
+1
-----Original Message-----
From: Owen Nichols <on...@vmware.com>
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" <kl...@apache.org> 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 we
plan to keep testing on Windows in CI.
Please vote or discuss.
Thanks,
Kirk
RE: [PROPOSAL] Add windows jobs to PR checks
Posted by Dick Cavender <di...@vmware.com>.
+1
-----Original Message-----
From: Owen Nichols <on...@vmware.com>
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" <kl...@apache.org> 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 we
plan to keep testing on Windows in CI.
Please vote or discuss.
Thanks,
Kirk
Re: [PROPOSAL] Add windows jobs to PR checks
Posted by Owen Nichols <on...@vmware.com>.
+1 for adding all JDK11 Windows tests to PR pipeline.
On 6/25/20, 9:29 AM, "Kirk Lund" <kl...@apache.org> 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 we
plan to keep testing on Windows in CI.
Please vote or discuss.
Thanks,
Kirk