On 4/13/22 3:51 PM, Ævar Arnfjörð Bjarmason 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.
>
> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx>
> ---
> diff --git a/ci/lib.sh b/ci/lib.sh
> @@ -1,6 +1,30 @@
> +# Usage
> +CI_TYPE_HELP_COMMANDS='
> + # run "make all test" like the "linux-leaks" job
> + (eval $(jobname=linux-leaks ci/lib.sh --all) && make test)
> +
> + # run "make all test" like the "linux-musl" job
> + (eval $(jobname=linux-musl ci/lib.sh --all) && make test)
> +
> + # run "make test" like the "linux-TEST-vars" job (uses various
GIT_TEST_* modes)
> + make && (eval $(jobname=linux-TEST-vars ci/lib.sh --test) && make test)
> +
> + # run "make test" like the "linux-sha256" job
> + make && (eval $(jobname=linux-sha256 ci/lib.sh --test) && make test)
> +'
> +
> +CI_TYPE_HELP="
> +running $0 outside of CI? You can use ci/lib.sh to set up your
> +environment like a given CI job. E.g.:
> +$CI_TYPE_HELP_COMMANDS
> +
> +note that some of these (e.g. the linux-musl one) may not work as
> +expected due to the CI job configuring a platform that may not match
> +yours."
> +
> @@ -9,6 +33,10 @@ mode=$1
> if test -z "$mode"
> then
> echo "need a $0 mode, e.g. --build or --test" >&2
> + if test -z "$CI_TYPE"
> + then
> + echo "$CI_TYPE_HELP" >&2
> + fi
> exit 1
> fi
It would never occur to me to try running a script named ci/lib.sh in
the first place, and I'm not sure I would even think to poke around in
the `ci` directory with the idea of being able to run CI tasks
locally. Would it make sense to aid discovery by mentioning this new
feature in the "GitHub CI" section of SubmittingPatches as a follow up
to this series? (If so, perhaps the "GitHub CI" section should be
renamed to "CI".)
> @@ -76,10 +108,29 @@ CC_PACKAGE=
> # How many jobs to run in parallel?
> NPROC=10
> +case "$CI_TYPE" in
> +'')
> + if command -v nproc >/dev/null
You need to redirect stderr too in order to avoid a scary error
message on platforms lacking `nproc`:
if command -v nproc >/dev/null 2>&1
> + then
> + NPROC=$(nproc)
> + else
> + NPROC=1
> + fi
Neither macOS nor BSD has an `nproc` command, however, they do have
`sysctl`:
elif command -v sysctl >/dev/null 2>&1
then # macOS & BSD
NPROC=$(sysctl -n hw.ncpu 2>/dev/null)
and Windows provides a suitable environment variable:
elif test -n "$NUMBER_OF_PROCESSORS"
then # Windows
NPROC="$NUMBER_OF_PROCESSORS"
> + if test -n "$MAKEFLAGS"
> + then
> + COMMON_MAKEFLAGS="$MAKEFLAGS"
> + else
> + COMMON_MAKEFLAGS=--jobs=$NPROC
> + fi
> + ;;
