Nilesh, Pierre, Thank you for the response. > > Yes please, making efforts to write tests is definitely worth it. From my experience, you might contact upstream developers to ask them for meaningful commands requiring no more data that the ones that are in the source tree. Friendly upstreams usually <ill try to answer! > I would second that. If possible, ask upstream for sensible data size that is manageable under a few MBs. I will reach out to the upstreams to see if they have any smaller test cases. > No, not really. autopkgtest has a `needs-internet` restriction, so you can access internet to get stuff. See here: > > https://people.debian.org/~eriberto/README.package-tests.html > > But yeah, this is usually better, since the server you fetch data from might choke someday, or might turn unresponsive or maybe block IPs if you do several `get` requests to it (which the CI machines would do) and so on, then that's a problem. Would it be acceptable to create salsa repos that hold the test data for various medical packages (pique-data, hinge-data)? After ensuring that the data sets are public domain with appropriate credit given, we could then reference a fixed salsa repo. It would still require the 'needs-internet' restriction but would ensure the data is available. Based on Tony's response in the thread, perhaps the data sets for this type of processing are large out of necessity? This is what led me to think of the above solution. Lance Lin <lqi254@protonmail.com> GPG Fingerprint: 8CAD 1250 8EE0 3A41 7223 03EC 7096 F91E D75D 028F
Attachment:
signature.asc
Description: OpenPGP digital signature