1. Forum
  2. Usenet
  3. LINUX.DEBIAN.DEVEL

  • Re: Bug#1104643: Don't consider tests during build that can use interne

    From Bill Allombert@1:229/2 to Pirate Praveen on Mon May 5 22:50:02 2025
    XPost: linux.debian.bugs.dist
    From: [email protected]

    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.

    autopkgtest has an option to allow network access, so you can use that.

    If you need the test to be performed as part of the build, propose a new DEB_BUILD_OPTION 'allownetworktest' and make your tests conditional on that.

    Cheers,
    --
    Bill. <[email protected]>

    Imagine a large red swirl here.

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Santiago Ruano =?iso-8859-1?Q?Rinc=@1:229/2 to All on Tue May 6 20:00:01 2025
    XPost: linux.debian.bugs.dist
    From: [email protected]

    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

    -----BEGIN PGP SIGNATURE-----

    iHUEABYIAB0WIQR+lHTq7mkJOyB6t2Un3j1FEEiG7wUCaBpMjgAKCRAn3j1FEEiG 71MJAP98POW/HhuKPmNj9mRBjbuSv+yjHNsReMSshfpAewa/fwD/R9ZBj8XcE9p/ We2CVRbmq9zbmCBRGvLl1D7exVCV9wA=
    =YIlL
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)