Subject: Re: [PATCH] fixup??? Merge branch 'ab/ci-updates' into seen

From: Junio C Hamano <[email-masked]>
Date: Tue, 23 Nov 2021 09:58:53 -0800

Ævar Arnfjörð Bjarmason <[email-masked]> writes:

> I'm pointing out that your patch to "master" has a logic error where you
> added the scalar tests after that case/esac, but on "master" any new
> "make new-test" needs to be added thusly:
>
>     diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
>     index cc62616d806..37df8e2397a 100755
>     --- a/ci/run-build-and-tests.sh
>     +++ b/ci/run-build-and-tests.sh
>     @@ -34,21 +34,28 @@ linux-gcc)
> ...
>      *)
>             make test
>     +       make new-test
>             ;;
>      esac
>     +"and not here, as it would run under pedantic"
>      
>      check_unignored_build_artifacts
>      
> As a result if you look at your own CI run's "pedantic" job at
> https://github.com/gitgitgadget/git/runs/4292915519?check_suite_focus=true
> you'll see that it runs the scalar test, which is not the
> intention. That job should be compile-only job with the -pedantic flag.

I think the above shows that it is a bug in the topic itself, but
the presense of the ab/ci-updates topic makes the issue harder to
see.  It makes the problem manifest in quite a different way.  The
band-aid we saw from Dscho does "fix" the manifestation after two
topics get merged (i.e. scalar build or test must follow the primary
build and cannot be done by itself), without correcting the original
bug (i.e.  scalar test is done in a wrong CI job).

Also, when writing recipes for CI, if you know that scalar build or
test must be preceded by primary build, I wonder if it is with more
good manners to write

	make test
-	make -C scalar test
+	make && make -C scalar test

to make the dendency clear?  In addition, it would be courteous to
the fellow developers to make the public entry points like "all" and
"test" self contained.  The Makefile of scalar knows as well as, or
better than, the developers that going up to the top-level of the
working tree and running "make" is required before "all" target can
be built, so automating that would help everybody from the trouble,
and the silly ugliness of "make && make -C there" I suggested above.

I do not, for example, mind at all if something silly like this was
done in contrib/scalar/Makefile:

    all: ../../git
    ../../git:
	$(MAKE) -C ../..
    test: all
	...

which is with clearly broken dependencies (e.g. if you edit
revision.c, scalar will not be rebuilt or the change would not
affect scalar's tests), but for the purpose of "letting CI build and
test from scratch to smoke out problems early", it is good enough.

Perhaps Ævar's suggestions were a lot more perfectionist than what
pragmatic me would say, and didn't mesh well with the test of Dscho
who is even more pragmatic than me?  In a separate message, Dscho
talks about weeks of delay, but it does not look to me that it is
solely Ævar's fault.

We know we hope to be able to make scalar as part of the top-level
offering from the project someday, but before that, we should make
sure it is as good as it has been advertiesed so far, and by not
even being able to easily integrate "correctly" (i.e. in line with
the design of the surrounding code) with the CI, we are stumbling at
the first step.

Thanks, both.