Right now one should avoid running tests, that require a network connection. As a result of that RESTRICT="test" is added to the ebuilds, although the tests would run fine if a network connection is available. This is especially bad for packages that talk to a fix remote server (e.g. youtube, mozilla sync, etc.). This proposal introduces RESTRICT="network-test" (maybe also just call it RESTRICT="network"), that should allow to run tests if FEATURES="network-test" is set ("network-test" and "network-sandbox" should be exclusive). If a subset of all tests require network access, one could remove those tests or prevent running them by checking the availability of FEATURES="network-test".
Bugzilla is broken and I can't move this bug, so I've opened a new one with ref to this in the correct product. *** This bug has been marked as a duplicate of bug 728658 ***
*** Bug 728658 has been marked as a duplicate of this bug. ***
How do we name the token, "network" or "network-test"?
(In reply to Ulrich Müller from comment #3) > How do we name the token, "network" or "network-test"? 'network-test', please, or even 'internet-test'. We want to emphasize it's about restricting tests, not disabling network-sandbox.
Ok, here's a slightly different idea. Let's extend RESTRICT syntax to make it 'token[:reason]', e.g. 'test:network', 'test:docker'. The idea behind that is that the first token is well-defined and always work, while the second one can have implementation-defined meaning. We can then add new reasons without any changes to the PMS, and old PMs will work just fine (assuming RESTRICT=test is effective).
In the end, I think two options are worth discussing: 1. Adding RESTRICT="network-test" in EAPI 8 that's independent of RESTRICT="test". 2. Adding PROPERTIES="network-test" (for all EAPIs) that changes semantics of RESTRICT="test". Option 1. has the advantage that you can specify RESTRICT="test" in addition to RESTRICT="network-test", e.g. when you need to disable tests temporarily for another reason. I don't think it's a big deal though, you could just comment out PROPERTIES="network-test" in the alternative scenario. Option 2. has the advantage that we can start using it today without bumping EAPI. I don't think it's a killer feature either but it would help me today ;-).
If we add a separate src_test_net phase for this, then ebuilds run networked tests separately. This can potentially add value by allowing network-sandbox to be used for the subset of tests which support network-sandbox, allowing network-related regressions in those tests to be caught.
I think it's probably better if we preserve the notion that RESTRICT="test" disables src_test. For ebuilds that have PROPERTIES="network-test", why don't we remove the need to set RESTRICT="test", and only execute src_test for these ebuilds when the user has FEATURES="network-test" enabled?
(In reply to Zac Medico from comment #8) > I think it's probably better if we preserve the notion that RESTRICT="test" > disables src_test. For ebuilds that have PROPERTIES="network-test", why > don't we remove the need to set RESTRICT="test", and only execute src_test > for these ebuilds when the user has FEATURES="network-test" enabled? That would break backwards compatibility.
You have to enable FEATURES="network-test" to "break" backward compatibility.
If you're concerned about the removal of RESTRICT=test, that's probably not a big deal because the intersection of people clinging to old portage versions that have FEATURES=test enabled globally is probably close to nil (it's never been practical to enable FEATURES=test globally).
Let's carry over the '_' prefix from USE_EXPAND, like: test_docker test_network
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=a88f4996a9c20a638c8bf9a42bcbbc28ce0cc8dc commit a88f4996a9c20a638c8bf9a42bcbbc28ce0cc8dc Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2021-05-12 15:53:15 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2021-05-19 08:06:38 +0000 Implement PROPERTIES=test_network and ALLOW_TEST The 'test_network' property can be used to indicate that the test phase requires access to the Internet (but RESTRICT=test should still be used). If present, network-sandbox will be disabled throughout the test phase. This opens up the possibility of adding further 'test_*' properties. Additionally, ALLOW_TEST can be used to ignore RESTRICT=test in a subset of packages. When the value includes 'network' token, tests using 'test_network' property are reenabled. When the value includes 'all' token, all instances of RESTRICT=test are ignored. Bug: https://bugs.gentoo.org/553696 Reviewed-by: Zac Medico <zmedico@gentoo.org> Acked-by: Ulrich Müller <ulm@gentoo.org> Signed-off-by: Michał Górny <mgorny@gentoo.org> bin/ebuild.sh | 3 ++- bin/phase-functions.sh | 8 +++++--- lib/portage/const.py | 2 +- .../package/ebuild/_config/special_env_vars.py | 3 ++- lib/portage/package/ebuild/config.py | 22 ++++++++++++++++++---- lib/portage/package/ebuild/doebuild.py | 15 +++++++++------ man/make.conf.5 | 21 ++++++++++++++++++++- 7 files changed, 57 insertions(+), 17 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/pms.git/commit/?id=e8a781295a5ea78570c5f186317a7cf4d5ae6758 commit e8a781295a5ea78570c5f186317a7cf4d5ae6758 Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2021-05-19 14:54:00 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2021-05-23 09:54:20 +0000 Recognise "test_network" as token in PROPERTIES This was originally proposed as a RESTRICT token for EAPI 8, but implementing it retroactively in PROPERTIES (where it is optional from the spec's point of view) appears to be more feasible. Bug: https://bugs.gentoo.org/553696 Signed-off-by: Ulrich Müller <ulm@gentoo.org> ebuild-vars.tex | 2 ++ 1 file changed, 2 insertions(+)
