On Wed, Jul 27 2022, Junio C Hamano wrote: > Derrick Stolee <derrickstolee@xxxxxxxxxx> 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@xxxxxxxxx/; 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?
