Mario Limonciello
Mario Limonciello
> @superm1 what does coverage.xml show? Is it an empty file or something weird perhaps? let's see, I just changed the job to save it to artifacts so we can...
It's empty!
My conclusion from that finding is something must have changed in the Debian container that broke coverage. It just starts to show up today because containers regenerated about 16 hours...
It's a bit difficult to run diff on without some fancy pants filtering tools. You got any good ways? [old_2_push_to_registry (debian-x86_64).txt](https://github.com/fwupd/fwupd/files/15152650/old_2_push_to_registry.debian-x86_64.txt) [new_2_push_to_registry (debian-x86_64).txt](https://github.com/fwupd/fwupd/files/15152648/new_2_push_to_registry.debian-x86_64.txt)
But at least for the biggies. * Same gcovr version 7.0-1 * Same GCC 13.2.0-23
It is a bit weird to be calling this on a device that isn't updatable, but yeah this does look like a bug very likely. Can you please share the...
> I'm not sure what the proper fix is here; they're both the same device. How about the daemon skips inhibited devices when processing `GetUpgrades`?
> @superm1 talking of testing -- do we have a plan for getting coverage back? At least physiologically seeing a number "go down" means we're more likely to write tests....
CC @hublin2024 @jimmytu5167 @andychu5168
@hughsie I wonder if we want a flag on devices that are known EVB/DVB IDs to require an extra nudge to do stuff to avoid this?