IPv6 support

[deavmi]

Would it be possible to update the version of node used to one that prefers IPv6 addresses when they are available (and applicable to the host)?

Or at least point out how I could go about doing so. Problems is I get this failure:

connect ENETUNREACH 188.114.97.3:443
::error::connect ENETUNREACH 188.114.97.3:443

I live in a remote village that only has IPv6, I have DNS64 but that of course works with IPv6 addresses only so it would be nice if the step which fetches the compiler could make use of a version of node that speaks it.

[Geod24]

Where do you see this problem ? Your own location should not affect this action, unless you use custom runners ?

[deavmi]

Yes, when running this action on an IPv6-only network (as mine), the action seems to crash because it fails to connect to a v4 address. There is no v4 on this machine, hence this smells to me like a pre-Node 17 problem (as such behavior doesn't occur in later versions - 17 onwards as I have read).

…

On 09 September 2024 23:53:06 SAST, Mathias LANG ***@***.***> wrote: Where do you see this problem ? Your own location should not affect this action, unless you use custom runners ? -- Reply to this email directly or view it on GitHub: #84 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

---- Tristan B. Velloza Kildaire Web: https://deavmi.assigned.network BNET IRC: deavmi Email: ***@***.***

[deavmi]

Where do you see this problem ? Your own location should not affect this action, unless you use custom runners ?

Here we go:

[deavmi]

I know where the problem occurs:

For some reason the code, when it fetches this, is preferring the IPv4 record, despite there being a V6 (AAAA) one. Which is the case at least on all DNS64 enabled machines.

[Geod24]

Once again, I don't see how your own location would affect the Github actions by default.
However searching for the error code shows that the issue might show up intermittently: actions/runner-images#3737
We are using Node 20 already so the issue mentioned seldom triggers. Could you link to the workflow that failed ?

[deavmi]

Once again, I don't see how your own location would affect the Github actions by default.

By this I meant I only have IPv6 access where I am. There is no ISP in my area with affordable IPv4. Anyways, that was an aside. Let me get the information on the failing workflow.

…

On 18 September 2024 15:09:31 SAST, Mathias LANG ***@***.***> wrote: Once again, I don't see how your own location would affect the Github actions by default. However searching for the error code shows that the issue might show up intermittently: actions/runner-images#3737 We are using Node 20 already so the issue mentioned seldom triggers. Could you link to the workflow that failed ? -- Reply to this email directly or view it on GitHub: #84 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

---- Tristan B. Velloza Kildaire Web: https://deavmi.assigned.network BNET IRC: deavmi Email: ***@***.***

[Geod24]

By this I meant I only have IPv6 access where I am. There is no ISP in my area with affordable IPv4. Anyways, that was an aside.

Nothing in Github actions depends on your own location. The runners are in a DC owned by Github somewhere. So your Github actions should not behave differently from my Github actions.

Let me get the information on the failing workflow.

👍

[deavmi]

I am using a custom runner. That is why.

…

On 19 September 2024 11:08:07 SAST, Mathias LANG ***@***.***> wrote: > By this I meant I only have IPv6 access where I am. There is no ISP in my area with affordable IPv4. Anyways, that was an aside. Nothing in Github actions depends on your own location. The runners are in a DC owned by Github somewhere. So your Github actions should not behave differently from my Github actions. > Let me get the information on the failing workflow. 👍 -- Reply to this email directly or view it on GitHub: #84 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

---- Tristan B. Velloza Kildaire Web: https://deavmi.assigned.network BNET IRC: deavmi Email: ***@***.***

[deavmi]

Is there any logging information that would help us debug this problem?

It seems to be failing when resolving one of the compiler download URLs. It always resolves to a A record (even if AAAA is available or only available)