wip: ci: Run tests against Android NDK

[sp1ritCS]

No description provided.

[jpakkane]

Instead of having a custom cross file, it would be better to create it with meson env2mfile. It would also test that functionality at the same time.

[sp1ritCS]

Maybe. The bigger issue I have is coercing the container build.py into being able to re-use the same built container for multiple test runs.

[dcbaker]

@thesamesam and @eli-schwartz Are the two that understand the CI system the best

[sp1ritCS]

I think the way I added the functionality was unnecessary actually. It seems like run_cross_tests actually supports that internally when passing multiple --cross arguments. I just figured that'd behave like meson itself does in merging the cross definitions.

This then obv. means I can't have split cross definitions like I had intended. Wouldn't be an issue with the env2mfile, but that has the issue of a) requiring meson during install and b) it generates a few dozen cross files but I don't want to run run_cross_tests a few dozen times.

[eli-schwartz]

Preliminary overview.

[eli-schwartz]

What is the purpose of this horribly unsafe variable indirection? Run the command properly?

[sp1ritCS]

I assume this was done in an attempt to get the google sdkmanager (which I guess has a handwritten arg parser) to accept a sdk root containing spaces. Wasn't possible tho.

But I guess, given that we moved from the google sdkmanager to the fdroid python reimplemetnation, which just uses argparse this should actually just work when removing the =.

[eli-schwartz]

To clarify my previous comment, these two lines are an incorrect and unsafe attempt to execute a command.

Removing the variable assignment and running the command properly will have the same semantic effect as the two lines which are there right now. The effect on sdkmanager is not strictly tied to that.

(Supporting spaces won't work either way, the variable isn't being quoted at the point of execution -- the second line -- which is a significantly greater problem and also incidentally a reason to stop incorrectly and unsafely storing a command with arguments inside a simple variable, as you cannot execute a variable as a command and sensibly quote one of the arguments stuffed inside the variable. Do not use shell variables to hold commands-with-arguments. Ever.)

[eli-schwartz]

In general it is very difficult to write a program on Unix (but very easy to write one on windows) that actually breaks on spaces in command line arguments. There are ways to break because of spaces, but they happen long after arguments are parsed.

The arg parser should never be related to the issue. Arguments are safely split up before the argument parser gets involved.

... Except on Windows, for Microsoft reasons. It is broadly speaking impossible to design software within the constraints of the Windows API and calling convention, that robustly and reliably parses arguments with spaces or special characters.

[sp1ritCS]

yes, I fully understood what you meant. Already moved it into one line. The fact that it was done with the variable was just the remains of some experimentation from my side when I wrote that initially.

But assuming you know that the whole variable only contains trusted input, whats the issue with running an unquoted variable as command with args?

[sp1ritCS]

In general it is very difficult to write a program on Unix [...] that actually breaks on spaces in command line arguments.

never underestimate the power of a multi-trillion dollar mega corporation that first shoves all arguments encoded as a single argument to java and then uses substring to take the part of the argument after = as value.

[eli-schwartz]

But assuming you know that the whole variable only contains trusted input, whats the issue with running an unquoted variable as command with args?

It has nothing whatsoever to do with trusted or untrusted input. Untrusted input is unsafe to eval. Mangling it in the invoked command's argv array is an application bug leading to unintended effects -- from a trust perspective it is no different from accepting different arguments equal to what the original arguments were misparsed as.

The actual issue is: It becomes difficult to read during code review.

• the logical flow is obscured
• the reviewer has to reason about when word splitting does and doesn't occur, and try to figure out if the word splitting was intended in all those places

It has no advantages and only confuses the reader. In the event that you actually need to save commands-with-arguments and "replay" them later, use an array!

[eli-schwartz]

never underestimate the power of a multi-trillion dollar mega corporation that first shoves all arguments encoded as a single argument to java and then uses substring to take the part of the argument after = as value.

I would argue that that's not an argument parser at all. :D

[thesamesam]

(Fixed the Gentoo builder in #15248.)

[sp1ritCS]

Does somebody know what causes the following: here the platform-android test cases succeed, where as they don't in my fork directly. I would expect them to fail, as I haven't yet rebased to include #15241. Does GHA somehow do an automatic auto-rebase on PRs?