You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After this commit, allocation tests in packages started failing on CI runs because, with Pkg.test(;coverage=true), allocations appear where with coverage=false they do not.
My simple example of such behavior (used to bisect the commit is):
This implied that CI tests that passed until v1.11.2 started failing on v1.11.3 and later versions.
The actual test that is being run in that package is:
using PDBTools
using BenchmarkTools
atoms =read_pdb(PDBTools.TESTPDB, "protein")
a =@benchmarksum($mass, $atoms) samples=1 evals=1@test a.allocs ==0
The text was updated successfully, but these errors were encountered:
lmiq
changed the title
allocation tests fail with coverage=true after https://github.com/JuliaLang/julia/commit/dfe6a13e5038c8cbe0f1720d190629225ec1a19b
allocation tests fail with coverage=true after dfe6a13e5038c8cbe0f1720d190629225ec1a19b
Jan 31, 2025
Yes probably. Is there a workaround? Some way to get the coverage report but in parallel run CI tests with the same compiler options that we use for production? (and thus, the ones which we test locally)
Is there a workaround? Some way to get the coverage report but in parallel run CI tests with the same compiler options that we use for production? (and thus, the ones which we test locally)
FixedSizeArrays works around this issue by splitting CI into coverage-enabled and coverage-disabled jobs. CI informs the test suite that "the build is a production build" when coverage is disabled, thus enabling the no-allocation tests:
The test suite needs to parse the environment variable:
See discussion at: https://discourse.julialang.org/t/tests-fail-on-ci-pass-locally/125140/11
After this commit, allocation tests in packages started failing on CI runs because, with
Pkg.test(;coverage=true)
, allocations appear where withcoverage=false
they do not.My simple example of such behavior (used to bisect the commit is):
This implied that CI tests that passed until v1.11.2 started failing on v1.11.3 and later versions.
The actual test that is being run in that package is:
The text was updated successfully, but these errors were encountered: