Re: [PATCH v4 31/31] CI: make it easy to use ci/*.sh outside of CI

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Apr 18 2022, Eric Sunshine wrote:

> On Mon, Apr 18, 2022 at 12:29 PM Ævar Arnfjörð Bjarmason
> <avarab@xxxxxxxxx> wrote:
>> In preceding commits the ci/.sh scripts have lost most of their
>> CI-specific assumptions. Let's go even further and explicitly support
>> running ci/lib.sh outside of CI.
>>
>> This was possible before by faking up enough CI-specific variables,
>> but as shown in the new "help" output being added here using the
>> ci/lib.sh to provide "CI-like" has now become trivial.
>>
>> The ci/print-test-failures.sh scripts can now be used outside of CI as
>> well, the only GitHub CI-specific part is now guarded by a check that
>> we'll pass if outside of GitHub CI.
>>
>> There's also a special-case here to not clobber $MAKEFLAGS in the
>> environment if we're outside of CI, in case the user has e.g. "jN" or
>> other flags to "make" that they'd prefer configured already.
>>
>> Using "ci/lib.sh" as a stand-alone script is much more useful if it
>> doesn't hardcode NPROC=10, let's provide a poor shellscript
>> replacement for the online_cpus() we have in thread-utils.c to cover
>> the most common OS's. It was suggested to use "2>&1" to invoke
>> "command -v", but per my reading of [2] and my own testing that
>> doesn't seem to be needed. Perhaps it's only needed for "which(1)"?
>
> Not redirecting stderr makes sense. I almost certainly accidentally
> typed "type foo" reflexively even though I meant to type "command -v
> foo", which explains why I thought redirecting stderr was needed. The
> explanation above probably would have best been done simply as a reply
> to the review thread rather than as part of the commit message, but
> dropping it from the commit message is not worth a reroll.

Thanks. I figured including it was worthwhile, since I'd probably on
another day have looked at it & mixed them up the same way, i.e. you
need the redirection for "which"...

>> 1. https://lore.kernel.org/git/214f8670-91d5-f4b6-efa1-76966c3ab1ee@xxxxxxxxxxxxxx/
>> 2. https://pubs.opengroup.org/onlinepubs/009604499/utilities/command.html
>>
>> Helped-by: Eric Sunshine <sunshine@xxxxxxxxxxxxxx>
>> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx>
>> ---
>> diff --git a/ci/lib-online_cpus.sh b/ci/lib-online_cpus.sh
>> @@ -0,0 +1,26 @@
>> +# TODO: Ideally we'd compile t/helper/test-online-cpus.c early, but
>> +# that presents a chicken & egg problem. But if we move it to a
>> +# stand-oline command...
>
> Um, what's a "stand-oline"?

Typo for stand-alone, sorry.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux