Re: [PATCH] ci(linux32): make Javascript Actions work in x86 mode

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Sep 17, 2024, 12:20 UTC
Message-ID: <d8b15f7e-7847-f6ff-cf8f-02aee254b070@gmx.de>
In-Reply-To: <xmqqr09krijc.fsf@gitster.g>

Hi,

On Sun, 15 Sep 2024, Junio C Hamano wrote:

Show 8 quoted lines

> Jeff King <peff@peff.net> writes:
>
> > On Sat, Sep 14, 2024 at 10:17:16AM -0700, Junio C Hamano wrote:
> >
> >> Each of these approaches may have its pros and cons, but I somehow
> >> do not see that the newly proposed alternative is 10x better than
> >> what was reviewed and queued already to be worth the effort to
> >> replace it.

Installing lib64stdc++ indeed does not rely on the implementation detail that `/__e/node20/` contains the Node version used to execute the Actions in those Docker containers.

Of course, the fact that installing lib64stdc++ (and no other 64-bit library) "fixes" the 64-bit Node version is also an implementation detail.

Between GitHub Actions' and Node's development speed, I personally would expect the latter implementation detail to be changed many times over before the former implementation detail would be changed.

In particular given that mapping the "externals" by any other name than `/__e/` risks breaking existing GitHub workflows that might make use of exactly that directory name, I consider the chances for that name change to be negligible. It probably won't change, ever.

Of course, my favorite solution would be for `actions/runner` to be fixed so that it detects the situation and uses a 32-bit variant in that case [*1*].

Business forces work against this wish, though, so I don't see this happening.

The next best thing, in my mind, is to come up with a solution that is general enough that other projects could follow this example, which is what I did.

And yes, the idea of mixing 32-bit and 64-bit things in a container that was specifically used to only have 32-bit things still does not convince me, it still looks like a much better idea to either stick with a 32-bit-only container, or to just do away with the complexity of a container altogether if the environment does not need to be free of 64-bit anyway (but why did we bother with that in the first place, then?).

Ciao, Johannes

Footnote *1*: I have added quite a few details about this here: https://github.com/actions/upload-artifact/issues/616#issuecomment-2350667347