On Tue, Apr 19 2022, Phillip Wood wrote:
>> * ab/ci-setup-simplify (2022-04-14) 29 commits
>> [...]
>> Will merge to 'next'?
>> source: <cover-v3-00.29-00000000000-20220413T194847Z-avarab@xxxxxxxxx>
>
> I haven't had time to read all 31 patches from v4 in detail but I have
> looked at the results in seen.
>
> Looking at seen:ci/install-dependencies.sh the shebang has been
> changed to "#!/bin/sh" but it contains
> "BREW_PACKAGE=${CC_PACKAGE/-/@}" which is a bashism.
>
> Looking at seen:.github/workflows/main.yaml to skip running the tests
> one has to set "skip-tests: no" which is utterly confusing.
>
> From what I saw scanning the patches there seemed to be a lot of
> churn, both of existing code and code that gets added and then
> moved/refactored within the series.
>
> Looking at the output of a recent ci run of seen the steps to prepare
> the environment before building and testing print all the environment
> variables rather than just the ones being set for that step which
> seems to go against the aim of "CI: narrow down variable definitions
> in --build and --test". (Also the "SKIP" prefix in the output lacks a
> ":")
Thanks. Those were all helpful. I replied to these in a re-roll CL at:
https://lore.kernel.org/git/cover-v5-00.29-00000000000-20220421T181526Z-avarab@xxxxxxxxx/
> Dscho raised concerns that this removes any support for azure
> pipelines which he uses when preparing security patches.
In the v1 discussion of my series ~2 months ago I asked him how he'd
prefer to proceed with that:
https://lore.kernel.org/git/220222.86y2236ndp.gmgdl@xxxxxxxxxxxxxxxxxxx/
There wasn't any reply to that for about a month so I submitted the v2,
noting that we might want to do something different there:
https://lore.kernel.org/git/cover-v2-00.25-00000000000-20220325T182534Z-avarab@xxxxxxxxx/
And then as a follow-up to that v2 there was a follow-up discussion
ending (from my side) here:
https://lore.kernel.org/git/220406.86bkxeecoi.gmgdl@xxxxxxxxxxxxxxxxxxx/
So, in brief summary I'm still happy to accommodate any such use-case.
But I don't think it's OK to say that code we don't even use in-tree in
area X must be kept as-is, to the point where it blocks forward progress
for things that are used in-tree.
To be clear: I'm not saying that's Johannes's position, it may or may
not be: The point is that he hasn't replied to
https://lore.kernel.org/git/220222.86y2236ndp.gmgdl@xxxxxxxxxxxxxxxxxxx/
or any relevant follow-up discussions. So I don't know what he's
expecting there, or if it can be reasonably accommodated in making
changes to ci/* which by their nature must decide to
support/keep/fork/remove some of that code.
> I think splitting out the build and test steps is a good idea but I'm
> less convinced by some of the other changes.
What other changes are you referring to here?
