Re: [PATCH] CI: add SANITIZE=[address|undefined] jobs
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Jul 28, 2022, 16:52 UTC
- Message-ID
- <220728.86sfmljhyx.gmgdl@evledraar.gmail.com>
- In-Reply-To
- <xmqqilnityp0.fsf@gitster.g>
On Wed, Jul 27 2022, Junio C Hamano wrote:
Show 35 quoted lines
> Derrick Stolee <derrickstolee@github.com> writes: > >>> - jobname: linux-leaks >>> cc: gcc >>> pool: ubuntu-latest >>> + - jobname: SANITIZE=address >>> + cc: gcc >>> + pool: ubuntu-latest >>> + - jobname: SANITIZE=undefined >>> + cc: gcc >>> + pool: ubuntu-latest >> >>> @@ -277,6 +277,12 @@ linux-leaks) >>> export SANITIZE=leak >>> export GIT_TEST_PASSING_SANITIZE_LEAK=true >>> ;; >>> +SANITIZE=address) >>> + export SANITIZE=address >>> + ;; >>> +SANITIZE=undefined) >>> + export SANITIZE=undefined >>> + ;; >> >> In both of these cases, we are breaking from the nearby pattern. These >> jobs could be renamed to linux-address and linux-undefined to match the >> linux-leaks job. >> >> Alternatively, we could rename linux-leaks to SANITIZE=leak, since the >> point is not to test the Linux platform but to use the additional runtime >> checks (and Linux is the fasted CI platform). > > I tend to agree that in the existing linux-leaks job, the > "linux"-ness is much less important than the "leaks"-ness, so the > "alternative" might be slightly more preferable, but I do not mind > the renaming goes the other way, either.
I'm fine with it either way, but to add a prep patch to this series to do s/linux-leaks/SANITIZE=leak/g would cause a semantic conflict with my in-flight https://lore.kernel.org/git/cover-v3-00.15-00000000000-20220727T230800Z-avarab@gmail.com/; It refers to "linux-leaks" in newly added documentation.
So what would you prefer here, to take a lightly altered re-roll of this (I think Jeff's suggestion of bundling "undefined" into one job makes sense), or have it build on top of that otherwise unrelated series, or just do the s/linux-leaks/.../g as an eventual follow-up?