Example output:
WERROR_CFLAGS="-Werror -pedantic-errors" MAKEFLAGS="-j4" BUILD="check" ECMULTWINDOW="auto" ECMULTGENPRECISION="auto" ASM="no" WIDEMUL="int64" WITH_VALGRIND="no" EXTRAFLAGS="" EXPERIMENTAL="no" ECDH="no" RECOVERY="yes" SCHNORRSIG="no" SECP256K1_TEST_ITERS="" BENCH="yes" SECP256K1_BENCH_ITERS="2" CTIMETEST="yes" EXAMPLES="yes" WRAPPER_CMD="" CC="gcc" AR="" NM="" HOST="" ./ci/cirrus.sh
@real-or-random Yes, I'm not sure how to view this (cat_env is skipped in the test runs I've looked at) and I suppose this contains a lot of stuff that is irrelevant. The goal of this PR is to quickly spot the relevant options in a failng CI task and be able to reproduce them (with high but certainly not perfect accuracy).
Yeah, it's skipped for successful tasks due to this line: https://github.com/bitcoin-core/secp256k1/blame/a43e982bca580f4fba19d7ffaf9b5ee3f51641cb/.cirrus.yml#L39
We should remove the line, I don't know why I included this...
I suppose this contains a lot of stuff that is irrelevant.
Right, that's a real drawback.
I'm not strongly opposed to this PR but it feels it increases our burden work because we'll have to update the list of "relevant" variables every time we add or remove a relevant variable, and this will be easily overlooked.
It doesn't seem straightforward to take the output of cat_test_env and run cirrus.sh. The lines are not necessarily shell variable assignments due to the spaces and newlines. Even if they were, it's not clear to me how to easily to run cirrus.sh with the same environment (and maybe it's even a bit scary, e.g., env contains PWD).
If there's no cleverer solution to this, I think it's fine to maintain the list of variables to make it easy to reproduce a test job.
We could make it slightly less fragile by setting the shell flag -u ("treat unset variables as an error"). See https://github.com/jonasnick/secp256k1/commit/d45ae832fdee9a9333dcbb2c2d01893fff508bd1 (passes CI). This would probably be worth doing regardless of this PR.
We could make it slightly less fragile by setting the shell flag
-u("treat unset variables as an error"). See jonasnick@d45ae83 (passes CI). This would probably be worth doing regardless of this PR.
We can do that but in what way would this be less fragile?
Slightly less fragile because the removal or renaming of any relevant variables that misses the newly added lines would result in an error.
ACK 4e54c03153a307af5cc80c7671ac7eef28138326
Slightly less fragile because the removal or renaming of any relevant variables that misses the newly added lines would result in an error.
Hm yes, though having unused variables actually unset (instead of set to the empty string) is also a good idea in CI because that's what the user will probably do. I'm fine either way, I think.