Repository navigation
Open
Labels
Description
hackage-server/exes/BuildClient.hs
Lines 654 to 666 in 1217eb0
| testPackage :: Verbosity -> BuildOpts -> DocInfo -> IO (Maybe String, Maybe FilePath, Maybe FilePath) | |
| testPackage verbosity opts docInfo = do | |
| let pkgid = docInfoPackage docInfo | |
| testLogFile = (installDirectory opts) </> display pkgid <.> "test" | |
| testReportFile = (installDirectory opts) </> "reports" </> display pkgid <.> "test" | |
| testResultFile = (resultsDirectory opts) </> display pkgid <.> "test" | |
| pkg_flags = | |
| ["all", | |
| "--enable-coverage", | |
| "--test-log=" ++ testReportFile, | |
| "--test-show-details=never", | |
| "--disable-optimization"] | |
| notice verbosity ("Testing " ++ display pkgid) |
IMO there are a few issues with this:
- Hiding
--test-show-detailsis very unhelpful. Presumably users are supposed to access--test-logsomehow, but I cannot find any link to it in UI. - Why
--disable-optimizations? This breaks inspection testing (fusion rules and such), here is an example: Inspection tests fail if -O0 is forced text#634 --enable-coverageprevents test execution for any package depending onvector(so pretty much any non-trivial package) because of
Resolving dependencies...
Error:
Internal libraries only supported with per-component builds.
Per-component builds were disabled because program coverage is enabled
In the package 'vector-0.13.2.0'
Activity
gbaz commentedon Jul 13, 2025
The first issue is a good call! I believe the plan was to add a ui to give access to the test build reports, but I can't find an issue for that. Imho that's the right solution.
On point two, I believe optimizations are disabled because they interact poorly with coverage.
Finally, on point three imho the right long term solution is to fix coverage with internal libraries. There is a workaround, but it appears to be somewhat tricky to implement as part of docbuilder, and really we "shouldn't" need it: haskell/cabal#6440
ulysses4ever commentedon Jul 13, 2025
Fun fact: cabal-install adopted
--test-show-details=directas the default since version 3.12 because people kept asking for it.Bodigrim commentedon Jul 13, 2025
While we wait for the long-term solution to arrive, could we enable test logs being reported directly for time being? It's very challenging to figure out what failed and why when there are no logs available.
Hmm, I don't recall any particular issues with regards to this. After all, the coverage metric we care about is when a package is used "normally", which means "with optimizations".
ysangkok commentedon Jul 14, 2025
The test logs are already available, as far as I can see. For example, for lens-5.3.5, click "build log" in the side bar. Then at the very bottom, there is a section called "Test log". The section is only shown if logs are available, as you can see in
report.html.st.Bodigrim commentedon Jul 14, 2025
That's build logs, but not test logs. If you look at the bottom of https://hackage.haskell.org/package/text-2.1.2/reports/2, it says "Error: cabal: Tests failed for text-2.1.2", but the failure is nowhere to be found.
There is no way to access
/var/lib/hackage-doc-builder/build-cache/tmp-install/reports/text-2.1.2.test.Bodigrim commentedon Sep 7, 2026
Thanks for working on test logs! However, I think #1417 does not cover all the points raised, the issues about
--disable-optimisationsand--enable-coveragestill stand.ysangkok commentedon Sep 7, 2026
Ok, for now I suppose we can just remove those two flags? Because having tests working for "non-trivial packages" seems more important than having coverage.
Bodigrim commentedon Sep 7, 2026
Yes, I think removing both flags is a reasonable way forward.
gbaz commentedon Sep 7, 2026
I believe that more recent cabals finally have coverage working with per-component builds? Can we put a pin in changing the flags until we conform the status of cabal and per-component builds
Bodigrim commentedon Sep 7, 2026
@gbaz I think the problem is that the test runner uses
v1-infrastructure, which can just barely cope with internal sublibraries, and enabling coverage pushes it over the limit. I don't recall any improvements in recent Cabals about it. So short of people willing to migrate the test runner tov2-, I'd say that getting tests without coverage is much better than not getting any tests at all (in the majority of cases).ysangkok commentedon Sep 7, 2026
The current BuildClient code seems to use
v2-test. But the problem does appear with cabal-install-3.10:I get another message if I pass
--enable-tests, so I didn't, since it seems BuildClient doesn't pass it either. With cabal-install-3.18, there is another issue with that package, with and without--enable-tests, but they seem unrelated:So this suggests to me that the issue would be resolved when cabal is updated on the Hackage builder.
philderbeast commentedon Sep 8, 2026
@ysangkok the
unknown package: chrome-test-utilsproblem testing this package stems from a test suite dependency not being on hackage, doesn't it? Thechrome-test-utilspackage is in the same reflex-dom repository.ysangkok commentedon Sep 8, 2026
@philderbeast Yes. So it is unrelated to whether per-component builds are supported with coverage, or not. I suspect the availability of a package could be a factor in whether the Cabal solver chooses to enable tests or not. So we might want to use
v2-test --enable-tests, but still, it's orthogonal.The second error message is, to me, the desired output of the Hackage test build report, which is why I pasted it.
philderbeast commentedon Sep 8, 2026
Just to note when this changed, for
cabal-install:exe:cabalwith version>= 3,v2-testandtestare the same:Bodigrim commentedon Sep 13, 2026
Ah, awesome, I stand corrected, thanks.
I imagine haskell-infra/hackage-doc-builder-config#25 can help with it.
The above covers the issue with
--enable-coverage. But are there any concerns about removing--disable-optimizations?