feat: REQUIRE_FEATURE / SKIP_FEATURE — applicability against the binary - #2
Merged
Merged
Conversation
A test can already say which run CONFIGURATION it applies to (REQUIRE_<TAG>).
It could not say which BUILD it applies to, and that is a different question:
a broker with an endpoint compiled out is indistinguishable from a full one
until asked, and the tests for that endpoint are not candidates for the run.
# REQUIRE_FEATURE: A B applies only if the build has ALL of them
# SKIP_FEATURE: A B applies only if the build has NONE of them
A separate mechanism from REQUIRE_<TAG> rather than another entry in the
value-matching arrays, because the matching is not the same. REQUIRE_<TAG>
holds ONE current value and asks whether it is among the alternatives, so
"REQUIRE_DB: corDB mongoc" means either. A feature list is a SET, and a test
that needs two features needs both — feeding it through the same arrays would
have made "REQUIRE_FEATURE: A B" mean "A or B", the opposite reading.
SKIP_FEATURE is the direction a reduced build needs: a test asserting the 501
for an endpoint that is not in the build can only run where it is not in the
build. Both drop the test from the run list rather than reporting it skipped,
the same as any REQUIRE_.
The set comes from COR_TEST_FEATURES, which the repo's corTestParams.sh sets —
normally by asking the binary what it was built with. UNSET means the repo does
not report features and both markers go inert: every test runs. That is the
loud failure rather than the quiet one, since a suite that silently skipped
everything on a broken detection would look green.
Also documents a REGEX() trap the above walked into: the pattern is spliced
into the line unbracketed, so a top-level | alternates the WHOLE line.
REGEX(true|false) accepts "true" and rejects "false" while looking correct.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TGatXwrHx1CreL49sCuS37
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A test can already say which run CONFIGURATION it applies to (
REQUIRE_<TAG>). It could not say which BUILD it applies to — a different question, and the one a feature-reduced broker needs.Why a separate mechanism rather than another entry in the value-matching arrays:
REQUIRE_<TAG>holds ONE current value and asks whether it is among the alternatives, soREQUIRE_DB: corDB mongocmeans either. A feature list is a SET, and a test needing two features needs both — the same arrays would have madeREQUIRE_FEATURE: A Bmean "A or B", the opposite reading.SKIP_FEATUREis the direction a reduced build needs: a test asserting the 501 for an endpoint that is not in the build can only run where it is not in the build. Both drop the test from the run list rather than reporting it skipped.The set comes from
COR_TEST_FEATURES, which the repo'scorTestParams.shsets — normally by asking the binary. UNSET means the repo does not report features and both markers go inert: every test runs. That is the loud failure rather than the quiet one; a suite that silently skipped everything on a broken detection would look green.Also documents a
REGEX()trap this walked into: the pattern is spliced into the line unbracketed, so a top-level|alternates the WHOLE line.REGEX(true|false)acceptstrueand rejectsfalsewhile looking correct.Exercised by coraine's
-DCOR_FEATURE_REGISTRATIONS=OFFbuild: 184 of 640 cases carryREQUIRE_FEATURE: REGISTRATIONSand leave the run set, one carriesSKIP_FEATUREand only runs there. Full build 640/640, reduced build 457/457.🤖 Generated with Claude Code
https://claude.ai/code/session_01TGatXwrHx1CreL49sCuS37