Allow maintainers to opt-out of tests

[gbaz]

Some tests are prohibitive to run on hackage, or require special resources or packages not available. It would be nice to allow maintainers to choose to opt out of such things.

P.S. (2022-03-25 by @andreasabel): As of today, you can opt out by uploading the documentation (via cabal upload -d) before the build/tests have run (#1037).

[andreasabel]

So what is the proposed design? Spinning some ideas:

1. Maybe a field:

   x-hackage-run-tests: False
   

   There could be other x-hackage fields like this: -build, -build-tests to opt out of building or building the tests.

2. Or just opt out of the banners:

   x-hackage-banner-build: False  
   x-hackage-banner-tests: False
   

3. Or flag-style:

   -- build and doc only
   x-hackage-banners: +build +doc      
   
   -- everything but tests
   x-hackage-banners: +all -tests
   

   (You get the idea.)

4. The same could be done for opting out of services (build, test, doc) altogether:

   x-hackage-service: +all -tests -doc
   

(Maybe there should be aliases for singular/plural: test == tests, doc = docs, x-hackage-service = x-hackage-services.)

[gbaz]

I'm not sure if we want to use a x- cabal field for such things. We currently don't let much of anything be driven by such fields, and also this means that maintainers can only alter things after the fact via a revision.

I would prefer we just add metadata state to packages which maintainers can set from the "maintainers corner".

[andreasabel]

I would prefer we just add metadata state to packages which maintainers can set from the "maintainers corner".

How does this metadata state work? Where/how is it stored and modified? Could you point me to some source locations? (I searched a bit for similar features, like deprecation and preferred versions, but my search was not conclusive. Also, opting out of services or banners would likely be a bit more lightweight, as it does not affect cabal.)

[gbaz]

State is stored using Acid-state in a number of distinct state components. I think the "preferred" path is probably a decent one to follow here -- create a new component storing this data (and perhaps some other data we anticipate letting maintainers set on packages while we're at it -- state migrations are possible but slightly irritating, so better to have more of what you want all at once on the first merge), then use acid-state to derive the storage methods for it, initialize the component on server startup, and allow it to be modified from the maintainers' corner., and consulted by hackage-server when it generates the page and also when the api is called that asks "ok, what do you want me (the builder) to build".

[gbaz]

PR #1124 lets us turn off tests for individual versions of a package. better still would also be allowing turning off tests for a package altogether.

• #1124