El 06/05/25 a las 02:20, Pirate Praveen escribió: > > On 06/05/2025 1:33 am, Bill Allombert wrote: > > On Tue, May 06, 2025 at 01:12:43AM +0530, Pirate Praveen wrote: > > > I think we have to consider test target in rules differently from build > > > targets as the effect on these on the final binaries we ship is different. > > > > > > I agree the current policy fit well when applied to the build target. As > > > we > > > don't want to ship anything not present / built from the source package. > > > > > > But anything runs in the test target does not affect the final binaries. > > > The > > > only difference that makes is more functionalities are tested. Because of > > > the current policy we are unable to test any functionality that needs an > > > internet connection. So I think the current policy is hiding potential > > > problems that could be discovered early if these tests are actually run > > > during build. > > That assumes that the buildd operators are willing to let your tests run > > with network access. > buildds don't need to allow it, only salsa ci and debci need to allow it.
WRT the salsa CI regular build jobs, as a user, I'd expect that they behave as close as possible to the buildds (we are not currently yet, but we have plans to move closer). Once the move to sbuild is completed, you could add --enable-network to the build arguments, but that should remain optional, and up to the maintainers. AFAIU, ci.d.n (if you refer to debci to it) runs autopkgtest with --no-built-binaries, so it doesn't apply. FWIW: https://salsa.debian.org/dsa-team/mirror/dsa-puppet/-/blob/2956ce9307f03c637001be34428d719958667661/modules/buildd/files/sbuild-wrapper#L127 Cheers, -- Santiago
signature.asc
Description: PGP signature
