config: test deterministic glob include ordering (v3) - #3281
Open
ssam18 wants to merge 1 commit into
Open
Conversation
Add config-includes-glob-order, which checks that a glob pattern in an include directive expands to all matching files and includes them in sorted order. glob.yaml includes *-order.yaml, matching three drop-in files (01/50/99) that each define their own unique marker key. The test asserts that all three keys are present in --dump-config output and that they appear in sorted-filename order, observable because the config tree preserves insertion order. No key is defined twice, so the test does not rely on duplicate-key override behavior. Include order matters because settings from later includes override earlier ones, which is what makes the numbered 01..99 drop-in convention predictable for users. The glob config is kept in glob.yaml and run via command: rather than a shipped suricata.yaml, because suricata-verify runs "suricata -c suricata.yaml --dump-config" during test setup before the min-version check. A glob include in suricata.yaml would break that setup step on Suricata versions without glob support. Until the Suricata side lands, a requires script greps src/conf-yaml-loader.c for the glob expansion code and skips the test on builds without it, the same way the eve-alert-metadata tests probe for METADATA_DEFAULTS. This keeps CI green against main and the release branches. A second requires script greps src/autoconf.h for HAVE_GLOB_H. Glob expansion needs glob(3), which Windows builds do not have; there an include pattern is skipped with a warning and none of the matched files are loaded, so the ordering checks could not hold. Probing the build rather than the platform keeps the test running everywhere glob(3) is available, including macOS and the BSDs. Exercises the include glob support added in OISF/suricata for this ticket. Ticket: #8427
This was referenced Aug 17, 2026
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
2 participants
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.
Depends on OISF/suricata#16031 (the
include:glob feature, Redmine #8427, superseding OISF/suricata#15937). This test exercises that feature, so CI here will stay red until it is merged intoOISF/suricata: suricata-verify CI builds suricata from the official branches (master/main-7.0.x/main-8.0.x), none of which have the feature yet. The pair is validated in the suricata PR's CI (which builds the feature and runs this exact branch viaSV_BRANCH) and locally.Previous PR: #3250
Changes since #3250
Rebased onto current
master. No changes to the test itself.This is what caused the CI failures on conf-yaml: support glob patterns in include directive (v3) suricata#15937: that PR's CI checked out this branch (via
SV_BRANCH) while it was still based on a June 5master, 119 commits behind. The 26 failing tests there (bug-8489-*,detect-email-*,mime-dec-*,ftp-reply-received-02,http2-keywords2) were all tests whose expectations were updated onmasteron July 21 to match newer suricatamainbehavior — none of them are the glob test added here, which passed.New PR rather than a force-push per the contribution workflow: the branch of an open PR should not be updated.
Adds
config-includes-glob-order, a test for theinclude:glob-pattern support added in OISF/suricata (Redmine #8427).glob.yamlincludes*-order.yaml, which matches three drop-in files (01-order.yaml,50-order.yaml,99-order.yaml). Each defines its own unique marker key (glob-order-seen-NN). Becauseglob(3)returns matches in sorted (lexicographic) order, the files are merged in ascending numeric-prefix order. The common01..99drop-in directory convention.Using
--dump-config, the test asserts:No key is defined twice, so the test does not depend on duplicate-key override behaviour. What it pins is the sort order, which is what the numbered drop-in convention relies on in practice.
The glob config is kept in
glob.yamland run viacommand:rather than a shippedsuricata.yaml, because suricata-verify runssuricata -c suricata.yaml --dump-configduring test setup, before themin-versioncheck.A
requires: script:probe grepssrc/conf-yaml-loader.cfor the glob expansion code so the test skips on builds without the feature, and a second probe grepssrc/autoconf.hforHAVE_GLOB_Hso it skips on builds withoutglob(3)(e.g. Windows), where an include pattern is skipped with a warning and the ordering checks cannot hold. See #3250 for the full history.Ticket: https://redmine.openinfosecfoundation.org/issues/8427