CI: Run the valgrind checks in parallel

[alexlarsson]

The valgrind tests keep timing out, but if we run the tests in parallel the
may succeed more often.

[alexlarsson]

I don't understand why its timing out in distcheck. Its not even reaching the valgrind check...

[mwleeds]

I don't understand why its timing out in distcheck. Its not even reaching the valgrind check...

The docs here for env say "A map of environment variables that are available to the steps of all jobs in the workflow." So it seems like we're running the whole test suite under valgrind twice, once under distcheck and once otherwise!

Not sure why distcheck belongs in the valgrind test anyway; seems like it would make more sense in "Build with gcc and test"?

[mwleeds]

As I said in #4962 there's an unrelated issue causing the "Build with gcc and test" job to fail

[mwleeds]

Moved two independently desirable commits from here into #4964 and merged them

[mwleeds]

I wonder if the valgrind test is timing out because it's in an infinite loop. When watching the log output of it, it doesn't seem to progress past "PASS: tests/[email protected] 8 update as bundle" which seems like good evidence for that hypothesis.

[mwleeds]

I wonder if the valgrind test is timing out because it's in an infinite loop. When watching the log output of it, it doesn't seem to progress past "PASS: tests/[email protected] 8 update as bundle" which seems like good evidence for that hypothesis.

And that is also the end of the log for one of the PRs where the valgrind check timed out #4957:

PASS: tests/[email protected] 8 update as bundle
Error: The operation was canceled.

[debarshiray]

Not sure why distcheck belongs in the valgrind test anyway; seems
like it would make more sense in "Build with gcc and test"?

That's from #4870, specifically 968169a:

workflows: Run distcheck

This lets us verify that our ability to do releases hasn't regressed.

Run this as part of the "valgrind" build, since we want to enable
gtk-doc for distcheck, and it's this build that already enables gtk-doc.
We don't want to do this in the main Autotools build, since
that enables AddressSanitizer, which often works badly with the
"scanner" tools in gtk-doc and GObject-Introspection - although this
is currently mitigated by --enable-asan not actually working as
intended (see https://github.com/flatpak/flatpak/pull/4844).

[debarshiray]

I don't understand why its timing out in distcheck. Its not even reaching the valgrind check...

The docs here for env say "A map of environment variables that are available to the steps of all jobs in the workflow." So it seems like we're running the whole test suite under valgrind twice, once under distcheck and once otherwise!

Umm... the documentation continues to say:

A map of environment variables that are available to the steps of
all jobs in the workflow. You can also set environment variables
that are only available to the steps of a single job or to a single step.

We seem to be doing it right.

[debarshiray]

I wonder if it has got something to do with the different versions of Ubuntu and the various libraries that are involved. The valgrind job is the only one that we have with Ubuntu 20.04.

[debarshiray]

The valgrind job is also stuck with flatpak-1.12.x. See #4976

[debarshiray]

The valgrind job is also stuck with flatpak-1.12.x. See #4976

I was wrong. I jumped to that conclusion too early -- the tests passed after 3 hours.