Re: debci/autopkgtest issue for static analysis tools [shellcheck]
Hello all,
On Sun, 22 Aug 2021 at 07:36, Paul Gevers <elbrus@debian.org> wrote:
> On 22-08-2021 01:18, Antonio Terceiro wrote:
> > static analysis tools are intended to run on in source code, while
> > autopkgtest is intended to run against installed packages, where source
> > code is in principle not relevant; we want to know whether the binary
> > packages, as provided in the Debian archive, work correctly.
> >
> > IMO running this type of tools as integration tests in autopkgtest, or
> > even as build-time tests is Wrong™, and should not be done. So I would
> > add another option:
>
> For what it's worth, I agree with Antonio both as one of the
> ci.d.n/autopkgtest maintainers *and* as a member of the Release Team. We
> don't want failing tests in testing and stable and we don't want allow
> "regressions" to migrate except for unless needed to solve RC bugs. As
> an RT member I claim we can always wait until bugs are fixed (or
> packages removed, see below).
>
> > D) report bugs requesting that those packages stop running shellcheck as
> > autopkgtest.
Ack, I'm not gonna argue against that.
> That would indeed be a new variant of the bug reports I regularly file
> (at RC level, so the offending package typically gets autoremoved). I'll
> try to remember to add text to this class of "regression" reports that
> removing the test is the preferred solution to the regression. As these
> bugs are always RC, they can even be NMU'ed.
Sounds good, though it might be a little bit of change in your
process, depending on how you're detecting those issues, as the
package which breaks is gonna be the static analysis tool, you would
need to check each blocker and target the bug report to it.
It seems like the next step here is to send a bug report to both
initramfs-tools and kdump-tools asking for the shellcheck's test to be
removed (or at the very least set it to flaky).
I would appreciate it if you could do it as part of your process,
Paul, as you could also sort out any disagreement with the
maintainers, but I can also do it myself if you'd like.
Thank you!
--
Samuel Henrique <samueloph>
Reply to: