Re: Failing IT's on Linux in GitHub Actions

2021-04-19 Thread Olivier Lamy 
yup definitely use loopback address (hostnames are not very reliable on
such ephemeral nodes environments)

On Mon, 19 Apr 2021 at 18:15, Tibor Digana  wrote:

> I had this problem with GH CI:
>
> java.net.BindException: Cannot assign requested address
> at sun.nio.ch.Net.bind0(Native Method)
> at sun.nio.ch.Net.bind(Net.java:461)
> at sun.nio.ch.Net.bind(Net.java:453)
> at
> sun.nio.ch
> .AsynchronousServerSocketChannelImpl.bind(AsynchronousServerSocketChannelImpl.java:163)
>
> and solved it see
>
> https://github.com/apache/maven-surefire/commit/a1d3866eb0dd81e8ea62f740f93fde93#diff-24d3dc1df1df617f7318394dde0b087beef68c26909828ccca72bf2af78ed9bfR84
> and now the CI is green.
> I guess we have the same problem in our ITs.
>
> T
>
>
>
>
>
>
> On Mon, Apr 19, 2021 at 10:09 AM Tibor Digana 
> wrote:
>
> > Port 0 does not exist, only in your code.
> > 0 means that a new unused local port is allocated.
> > Again you have to use local loopback 127.0.0.1 as me. I had the same
> > problem and I solved it.
> > T
> >
> > On Mon, Apr 19, 2021 at 8:41 AM Maarten Mulders 
> > wrote:
> >
> >> All of those tests seem to follow the process of starting a server at
> >> port 0 indeed. Some tests even start two servers in one test:
> >> MavenITmng4991NonProxyHostsTest and MavenITmng2387InactiveProxyTest. And
> >> in all three scenarios they use
> >> `InetAddress.getLocalHost().getCanonicalHostName()` to lookup their
> >> hostname. I'm not sure if that's the best way to do it?
> >>
> >> Interestingly, I now see that those tests do not *always* fail on Linux.
> >> During the last GitHub Action run (640, [1]), two out of four Linux jobs
> >> actually succeeded. The failing ones logged stuff like this:
> >>
> >>
> >> Connect to fv-az154-166.internal.cloudapp.net:34307
> >> [fv-az154-166.internal.cloudapp.net/10.1.0.103] failed: Connection
> timed
> >> out (Connection timed out)
> >>
> >> Connect to fv-az292-806.internal.cloudapp.net:33785
> >> [fv-az292-806.internal.cloudapp.net/10.1.0.129] failed: Connection
> timed
> >> out (Connection timed out)
> >>
> >>
> >> Interestingly, they seem to not be able to connect, but the name lookup
> >> doesn't seem the issue, right?
> >>
> >>
> >> Thanks,
> >>
> >>
> >> Maarten
> >>
> >>
> >> [1] https://github.com/apache/maven/actions/runs/761300517
> >>
> >>
> >> On 19/04/2021 00:31, Tibor Digaňa wrote:
> >> > yes, there was one more issue with host.
> >> > I also had to turn "localhost" to 127.0.0.1 in the socket.
> >> > T
> >> >
> >> > On Sun, Apr 18, 2021 at 11:48 PM Olivier Lamy 
> wrote:
> >> >
> >> >> Hi,
> >> >> Do not change ports or use hard coded ports.
> >> >> The current ITs are using port 0 which means Jetty will allocate a
> >> >> random available port.
> >> >> There must be some problems with host lookup. In some environments
> >> (such as
> >> >> kubernetes) using localhost or 127.0.0.1 can be problematic.
> >> >> What is the error?
> >> >>
> >> >> What is the status of using java8 for IT tests? (current ITs are
> using
> >> a
> >> >> very very old version of Jetty 9.0.4...)
> >> >>
> >> >>
> >> >> On Mon, 19 Apr 2021 at 06:56, Tibor Digana 
> >> wrote:
> >> >>
> >> >>> I had exactly the same problem and I added one more step to the CI
> >> which
> >> >>> checked all open ports.
> >> >>> For instance they changed something in Github and 8081 or 8082 was
> >> >>> allocated.
> >> >>> There was a conflict with the ports and I had to shift mine, that;s
> >> it.
> >> >>>
> >> >>> T
> >> >>>
> >> >>> On Sun, Apr 18, 2021 at 8:17 PM Maarten Mulders <
> >> mthmuld...@apache.org>
> >> >>> wrote:
> >> >>>
> >>  Hi all,
> >> 
> >>  It seems the following IT's predictably fail on Linux (not on
> Windows
> >> >> or
> >>  MacOS) in GitHub Actions, but not at all in Jenkins:
> >> 
> >>  * MavenIT0146InstallerSnapshotNaming
> >>  * MavenITmng2387InactiveProxyTest
> >>  * MavenITmng4991NonProxyHostsTest
> >> 
> >>  This is also the case in master, by the way. What they have in
> common
> >> >> is
> >>  that they all spin up an HTTP server during the test, but
> apparently
> >>  that server cannot be reached under all circumstances.
> >> 
> >>  Does anyone have an idea what might be causing this and how we
> could
> >>  address this?
> >> 
> >>  Thanks,
> >> 
> >>  Maarten
> >> 
> >> 
> -
> >>  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>  For additional commands, e-mail: dev-h...@maven.apache.org
> >> 
> >> 
> >> >>>
> >> >>
> >> >>
> >> >> --
> >> >> Olivier Lamy
> >> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >> >>
> >> >
> >> >
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
>


-- 
Olivier Lamy

Re: Failing IT's on Linux in GitHub Actions

2021-04-19 Thread Tibor Digana 
I had this problem with GH CI:

java.net.BindException: Cannot assign requested address
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:461)
at sun.nio.ch.Net.bind(Net.java:453)
at
sun.nio.ch.AsynchronousServerSocketChannelImpl.bind(AsynchronousServerSocketChannelImpl.java:163)

and solved it see
https://github.com/apache/maven-surefire/commit/a1d3866eb0dd81e8ea62f740f93fde93#diff-24d3dc1df1df617f7318394dde0b087beef68c26909828ccca72bf2af78ed9bfR84
and now the CI is green.
I guess we have the same problem in our ITs.

T






On Mon, Apr 19, 2021 at 10:09 AM Tibor Digana 
wrote:

> Port 0 does not exist, only in your code.
> 0 means that a new unused local port is allocated.
> Again you have to use local loopback 127.0.0.1 as me. I had the same
> problem and I solved it.
> T
>
> On Mon, Apr 19, 2021 at 8:41 AM Maarten Mulders 
> wrote:
>
>> All of those tests seem to follow the process of starting a server at
>> port 0 indeed. Some tests even start two servers in one test:
>> MavenITmng4991NonProxyHostsTest and MavenITmng2387InactiveProxyTest. And
>> in all three scenarios they use
>> `InetAddress.getLocalHost().getCanonicalHostName()` to lookup their
>> hostname. I'm not sure if that's the best way to do it?
>>
>> Interestingly, I now see that those tests do not *always* fail on Linux.
>> During the last GitHub Action run (640, [1]), two out of four Linux jobs
>> actually succeeded. The failing ones logged stuff like this:
>>
>>
>> Connect to fv-az154-166.internal.cloudapp.net:34307
>> [fv-az154-166.internal.cloudapp.net/10.1.0.103] failed: Connection timed
>> out (Connection timed out)
>>
>> Connect to fv-az292-806.internal.cloudapp.net:33785
>> [fv-az292-806.internal.cloudapp.net/10.1.0.129] failed: Connection timed
>> out (Connection timed out)
>>
>>
>> Interestingly, they seem to not be able to connect, but the name lookup
>> doesn't seem the issue, right?
>>
>>
>> Thanks,
>>
>>
>> Maarten
>>
>>
>> [1] https://github.com/apache/maven/actions/runs/761300517
>>
>>
>> On 19/04/2021 00:31, Tibor Digaňa wrote:
>> > yes, there was one more issue with host.
>> > I also had to turn "localhost" to 127.0.0.1 in the socket.
>> > T
>> >
>> > On Sun, Apr 18, 2021 at 11:48 PM Olivier Lamy  wrote:
>> >
>> >> Hi,
>> >> Do not change ports or use hard coded ports.
>> >> The current ITs are using port 0 which means Jetty will allocate a
>> >> random available port.
>> >> There must be some problems with host lookup. In some environments
>> (such as
>> >> kubernetes) using localhost or 127.0.0.1 can be problematic.
>> >> What is the error?
>> >>
>> >> What is the status of using java8 for IT tests? (current ITs are using
>> a
>> >> very very old version of Jetty 9.0.4...)
>> >>
>> >>
>> >> On Mon, 19 Apr 2021 at 06:56, Tibor Digana 
>> wrote:
>> >>
>> >>> I had exactly the same problem and I added one more step to the CI
>> which
>> >>> checked all open ports.
>> >>> For instance they changed something in Github and 8081 or 8082 was
>> >>> allocated.
>> >>> There was a conflict with the ports and I had to shift mine, that;s
>> it.
>> >>>
>> >>> T
>> >>>
>> >>> On Sun, Apr 18, 2021 at 8:17 PM Maarten Mulders <
>> mthmuld...@apache.org>
>> >>> wrote:
>> >>>
>>  Hi all,
>> 
>>  It seems the following IT's predictably fail on Linux (not on Windows
>> >> or
>>  MacOS) in GitHub Actions, but not at all in Jenkins:
>> 
>>  * MavenIT0146InstallerSnapshotNaming
>>  * MavenITmng2387InactiveProxyTest
>>  * MavenITmng4991NonProxyHostsTest
>> 
>>  This is also the case in master, by the way. What they have in common
>> >> is
>>  that they all spin up an HTTP server during the test, but apparently
>>  that server cannot be reached under all circumstances.
>> 
>>  Does anyone have an idea what might be causing this and how we could
>>  address this?
>> 
>>  Thanks,
>> 
>>  Maarten
>> 
>>  -
>>  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>  For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> 
>> >>>
>> >>
>> >>
>> >> --
>> >> Olivier Lamy
>> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
>> >>
>> >
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>

Re: Failing IT's on Linux in GitHub Actions

2021-04-19 Thread Tibor Digana 
Port 0 does not exist, only in your code.
0 means that a new unused local port is allocated.
Again you have to use local loopback 127.0.0.1 as me. I had the same
problem and I solved it.
T

On Mon, Apr 19, 2021 at 8:41 AM Maarten Mulders 
wrote:

> All of those tests seem to follow the process of starting a server at
> port 0 indeed. Some tests even start two servers in one test:
> MavenITmng4991NonProxyHostsTest and MavenITmng2387InactiveProxyTest. And
> in all three scenarios they use
> `InetAddress.getLocalHost().getCanonicalHostName()` to lookup their
> hostname. I'm not sure if that's the best way to do it?
>
> Interestingly, I now see that those tests do not *always* fail on Linux.
> During the last GitHub Action run (640, [1]), two out of four Linux jobs
> actually succeeded. The failing ones logged stuff like this:
>
>
> Connect to fv-az154-166.internal.cloudapp.net:34307
> [fv-az154-166.internal.cloudapp.net/10.1.0.103] failed: Connection timed
> out (Connection timed out)
>
> Connect to fv-az292-806.internal.cloudapp.net:33785
> [fv-az292-806.internal.cloudapp.net/10.1.0.129] failed: Connection timed
> out (Connection timed out)
>
>
> Interestingly, they seem to not be able to connect, but the name lookup
> doesn't seem the issue, right?
>
>
> Thanks,
>
>
> Maarten
>
>
> [1] https://github.com/apache/maven/actions/runs/761300517
>
>
> On 19/04/2021 00:31, Tibor Digaňa wrote:
> > yes, there was one more issue with host.
> > I also had to turn "localhost" to 127.0.0.1 in the socket.
> > T
> >
> > On Sun, Apr 18, 2021 at 11:48 PM Olivier Lamy  wrote:
> >
> >> Hi,
> >> Do not change ports or use hard coded ports.
> >> The current ITs are using port 0 which means Jetty will allocate a
> >> random available port.
> >> There must be some problems with host lookup. In some environments
> (such as
> >> kubernetes) using localhost or 127.0.0.1 can be problematic.
> >> What is the error?
> >>
> >> What is the status of using java8 for IT tests? (current ITs are using a
> >> very very old version of Jetty 9.0.4...)
> >>
> >>
> >> On Mon, 19 Apr 2021 at 06:56, Tibor Digana 
> wrote:
> >>
> >>> I had exactly the same problem and I added one more step to the CI
> which
> >>> checked all open ports.
> >>> For instance they changed something in Github and 8081 or 8082 was
> >>> allocated.
> >>> There was a conflict with the ports and I had to shift mine, that;s it.
> >>>
> >>> T
> >>>
> >>> On Sun, Apr 18, 2021 at 8:17 PM Maarten Mulders  >
> >>> wrote:
> >>>
>  Hi all,
> 
>  It seems the following IT's predictably fail on Linux (not on Windows
> >> or
>  MacOS) in GitHub Actions, but not at all in Jenkins:
> 
>  * MavenIT0146InstallerSnapshotNaming
>  * MavenITmng2387InactiveProxyTest
>  * MavenITmng4991NonProxyHostsTest
> 
>  This is also the case in master, by the way. What they have in common
> >> is
>  that they all spin up an HTTP server during the test, but apparently
>  that server cannot be reached under all circumstances.
> 
>  Does anyone have an idea what might be causing this and how we could
>  address this?
> 
>  Thanks,
> 
>  Maarten
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>  For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 
> >>>
> >>
> >>
> >> --
> >> Olivier Lamy
> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >>
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Failing IT's on Linux in GitHub Actions

2021-04-19 Thread Romain Manni-Bucau 
Hi

Should we set java.net.preferIPv4Stack=true?

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 19 avr. 2021 à 08:41, Maarten Mulders  a
écrit :

> All of those tests seem to follow the process of starting a server at
> port 0 indeed. Some tests even start two servers in one test:
> MavenITmng4991NonProxyHostsTest and MavenITmng2387InactiveProxyTest. And
> in all three scenarios they use
> `InetAddress.getLocalHost().getCanonicalHostName()` to lookup their
> hostname. I'm not sure if that's the best way to do it?
>
> Interestingly, I now see that those tests do not *always* fail on Linux.
> During the last GitHub Action run (640, [1]), two out of four Linux jobs
> actually succeeded. The failing ones logged stuff like this:
>
>
> Connect to fv-az154-166.internal.cloudapp.net:34307
> [fv-az154-166.internal.cloudapp.net/10.1.0.103] failed: Connection timed
> out (Connection timed out)
>
> Connect to fv-az292-806.internal.cloudapp.net:33785
> [fv-az292-806.internal.cloudapp.net/10.1.0.129] failed: Connection timed
> out (Connection timed out)
>
>
> Interestingly, they seem to not be able to connect, but the name lookup
> doesn't seem the issue, right?
>
>
> Thanks,
>
>
> Maarten
>
>
> [1] https://github.com/apache/maven/actions/runs/761300517
>
>
> On 19/04/2021 00:31, Tibor Digaňa wrote:
> > yes, there was one more issue with host.
> > I also had to turn "localhost" to 127.0.0.1 in the socket.
> > T
> >
> > On Sun, Apr 18, 2021 at 11:48 PM Olivier Lamy  wrote:
> >
> >> Hi,
> >> Do not change ports or use hard coded ports.
> >> The current ITs are using port 0 which means Jetty will allocate a
> >> random available port.
> >> There must be some problems with host lookup. In some environments
> (such as
> >> kubernetes) using localhost or 127.0.0.1 can be problematic.
> >> What is the error?
> >>
> >> What is the status of using java8 for IT tests? (current ITs are using a
> >> very very old version of Jetty 9.0.4...)
> >>
> >>
> >> On Mon, 19 Apr 2021 at 06:56, Tibor Digana 
> wrote:
> >>
> >>> I had exactly the same problem and I added one more step to the CI
> which
> >>> checked all open ports.
> >>> For instance they changed something in Github and 8081 or 8082 was
> >>> allocated.
> >>> There was a conflict with the ports and I had to shift mine, that;s it.
> >>>
> >>> T
> >>>
> >>> On Sun, Apr 18, 2021 at 8:17 PM Maarten Mulders  >
> >>> wrote:
> >>>
>  Hi all,
> 
>  It seems the following IT's predictably fail on Linux (not on Windows
> >> or
>  MacOS) in GitHub Actions, but not at all in Jenkins:
> 
>  * MavenIT0146InstallerSnapshotNaming
>  * MavenITmng2387InactiveProxyTest
>  * MavenITmng4991NonProxyHostsTest
> 
>  This is also the case in master, by the way. What they have in common
> >> is
>  that they all spin up an HTTP server during the test, but apparently
>  that server cannot be reached under all circumstances.
> 
>  Does anyone have an idea what might be causing this and how we could
>  address this?
> 
>  Thanks,
> 
>  Maarten
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>  For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 
> >>>
> >>
> >>
> >> --
> >> Olivier Lamy
> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >>
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Failing IT's on Linux in GitHub Actions

2021-04-19 Thread Maarten Mulders 
All of those tests seem to follow the process of starting a server at 
port 0 indeed. Some tests even start two servers in one test: 
MavenITmng4991NonProxyHostsTest and MavenITmng2387InactiveProxyTest. And 
in all three scenarios they use 
`InetAddress.getLocalHost().getCanonicalHostName()` to lookup their 
hostname. I'm not sure if that's the best way to do it?


Interestingly, I now see that those tests do not *always* fail on Linux. 
During the last GitHub Action run (640, [1]), two out of four Linux jobs 
actually succeeded. The failing ones logged stuff like this:



Connect to fv-az154-166.internal.cloudapp.net:34307 
[fv-az154-166.internal.cloudapp.net/10.1.0.103] failed: Connection timed 
out (Connection timed out)


Connect to fv-az292-806.internal.cloudapp.net:33785 
[fv-az292-806.internal.cloudapp.net/10.1.0.129] failed: Connection timed 
out (Connection timed out)



Interestingly, they seem to not be able to connect, but the name lookup 
doesn't seem the issue, right?



Thanks,


Maarten


[1] https://github.com/apache/maven/actions/runs/761300517


On 19/04/2021 00:31, Tibor Digaňa wrote:

yes, there was one more issue with host.
I also had to turn "localhost" to 127.0.0.1 in the socket.
T

On Sun, Apr 18, 2021 at 11:48 PM Olivier Lamy  wrote:


Hi,
Do not change ports or use hard coded ports.
The current ITs are using port 0 which means Jetty will allocate a
random available port.
There must be some problems with host lookup. In some environments (such as
kubernetes) using localhost or 127.0.0.1 can be problematic.
What is the error?

What is the status of using java8 for IT tests? (current ITs are using a
very very old version of Jetty 9.0.4...)


On Mon, 19 Apr 2021 at 06:56, Tibor Digana  wrote:


I had exactly the same problem and I added one more step to the CI which
checked all open ports.
For instance they changed something in Github and 8081 or 8082 was
allocated.
There was a conflict with the ports and I had to shift mine, that;s it.

T

On Sun, Apr 18, 2021 at 8:17 PM Maarten Mulders 
wrote:


Hi all,

It seems the following IT's predictably fail on Linux (not on Windows

or

MacOS) in GitHub Actions, but not at all in Jenkins:

* MavenIT0146InstallerSnapshotNaming
* MavenITmng2387InactiveProxyTest
* MavenITmng4991NonProxyHostsTest

This is also the case in master, by the way. What they have in common

is

that they all spin up an HTTP server during the test, but apparently
that server cannot be reached under all circumstances.

Does anyone have an idea what might be causing this and how we could
address this?

Thanks,

Maarten

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org







--
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy






-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Failing IT's on Linux in GitHub Actions

2021-04-18 Thread Tibor Digaňa 
yes, there was one more issue with host.
I also had to turn "localhost" to 127.0.0.1 in the socket.
T

On Sun, Apr 18, 2021 at 11:48 PM Olivier Lamy  wrote:

> Hi,
> Do not change ports or use hard coded ports.
> The current ITs are using port 0 which means Jetty will allocate a
> random available port.
> There must be some problems with host lookup. In some environments (such as
> kubernetes) using localhost or 127.0.0.1 can be problematic.
> What is the error?
>
> What is the status of using java8 for IT tests? (current ITs are using a
> very very old version of Jetty 9.0.4...)
>
>
> On Mon, 19 Apr 2021 at 06:56, Tibor Digana  wrote:
>
> > I had exactly the same problem and I added one more step to the CI which
> > checked all open ports.
> > For instance they changed something in Github and 8081 or 8082 was
> > allocated.
> > There was a conflict with the ports and I had to shift mine, that;s it.
> >
> > T
> >
> > On Sun, Apr 18, 2021 at 8:17 PM Maarten Mulders 
> > wrote:
> >
> > > Hi all,
> > >
> > > It seems the following IT's predictably fail on Linux (not on Windows
> or
> > > MacOS) in GitHub Actions, but not at all in Jenkins:
> > >
> > > * MavenIT0146InstallerSnapshotNaming
> > > * MavenITmng2387InactiveProxyTest
> > > * MavenITmng4991NonProxyHostsTest
> > >
> > > This is also the case in master, by the way. What they have in common
> is
> > > that they all spin up an HTTP server during the test, but apparently
> > > that server cannot be reached under all circumstances.
> > >
> > > Does anyone have an idea what might be causing this and how we could
> > > address this?
> > >
> > > Thanks,
> > >
> > > Maarten
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>


-- 
Cheers
Tibor

Re: Failing IT's on Linux in GitHub Actions

2021-04-18 Thread Olivier Lamy 
Hi,
Do not change ports or use hard coded ports.
The current ITs are using port 0 which means Jetty will allocate a
random available port.
There must be some problems with host lookup. In some environments (such as
kubernetes) using localhost or 127.0.0.1 can be problematic.
What is the error?

What is the status of using java8 for IT tests? (current ITs are using a
very very old version of Jetty 9.0.4...)


On Mon, 19 Apr 2021 at 06:56, Tibor Digana  wrote:

> I had exactly the same problem and I added one more step to the CI which
> checked all open ports.
> For instance they changed something in Github and 8081 or 8082 was
> allocated.
> There was a conflict with the ports and I had to shift mine, that;s it.
>
> T
>
> On Sun, Apr 18, 2021 at 8:17 PM Maarten Mulders 
> wrote:
>
> > Hi all,
> >
> > It seems the following IT's predictably fail on Linux (not on Windows or
> > MacOS) in GitHub Actions, but not at all in Jenkins:
> >
> > * MavenIT0146InstallerSnapshotNaming
> > * MavenITmng2387InactiveProxyTest
> > * MavenITmng4991NonProxyHostsTest
> >
> > This is also the case in master, by the way. What they have in common is
> > that they all spin up an HTTP server during the test, but apparently
> > that server cannot be reached under all circumstances.
> >
> > Does anyone have an idea what might be causing this and how we could
> > address this?
> >
> > Thanks,
> >
> > Maarten
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>


-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Failing IT's on Linux in GitHub Actions

2021-04-18 Thread Tibor Digana 
I had exactly the same problem and I added one more step to the CI which
checked all open ports.
For instance they changed something in Github and 8081 or 8082 was
allocated.
There was a conflict with the ports and I had to shift mine, that;s it.

T

On Sun, Apr 18, 2021 at 8:17 PM Maarten Mulders 
wrote:

> Hi all,
>
> It seems the following IT's predictably fail on Linux (not on Windows or
> MacOS) in GitHub Actions, but not at all in Jenkins:
>
> * MavenIT0146InstallerSnapshotNaming
> * MavenITmng2387InactiveProxyTest
> * MavenITmng4991NonProxyHostsTest
>
> This is also the case in master, by the way. What they have in common is
> that they all spin up an HTTP server during the test, but apparently
> that server cannot be reached under all circumstances.
>
> Does anyone have an idea what might be causing this and how we could
> address this?
>
> Thanks,
>
> Maarten
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Failing IT's on Linux in GitHub Actions

2021-04-18 Thread Maarten Mulders 

Hi all,

It seems the following IT's predictably fail on Linux (not on Windows or 
MacOS) in GitHub Actions, but not at all in Jenkins:


* MavenIT0146InstallerSnapshotNaming
* MavenITmng2387InactiveProxyTest
* MavenITmng4991NonProxyHostsTest

This is also the case in master, by the way. What they have in common is 
that they all spin up an HTTP server during the test, but apparently 
that server cannot be reached under all circumstances.


Does anyone have an idea what might be causing this and how we could 
address this?


Thanks,

Maarten

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org