feat: automatic Splunk version discovery#214
Conversation
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Add get_all_major_minor_versions() and get_new_versions() to discover new Splunk major.minor versions from Docker Hub. Include test scaffold with 4 tests covering discovery logic. Add pytest to requirements. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Adds add_new_version_stanza() function to create config stanzas for newly discovered Splunk versions. Returns True if stanza was added, False if version is expired or has no Docker image. Always sets PYTHON39=true and PYTHON37=false on new stanzas. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Implements remove_expired_versions() to prune stanzas with expired support dates (skipping UNKNOWN entries) and update_general_section() to sync LATEST/OLDEST values based on semver ordering. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Replaces the body of update_splunk_version() to call get_new_versions, add_new_version_stanza, remove_expired_versions, and update_general_section in addition to the existing patch-version update loop. Adds integration test covering new-minor discovery, patch bump, and GENERAL sync end-to-end. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 15dcaefc3a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| config.set(major_minor, "VERSION", latest_version) | ||
| if build: | ||
| config.set(major_minor, "BUILD", build) | ||
| config.set(major_minor, "SUPPORTED", supported) |
There was a problem hiding this comment.
Avoid writing UNKNOWN support dates
When get_supported_date() returns UNKNOWN for a scrape/network failure or an unlisted version, this still commits a new stanza with SUPPORTED = UNKNOWN. The Docker action consumer does not accept that value: _generate_supported_splunk() in addonfactory_test_matrix_action/main.py unconditionally runs datetime.strptime(supported_splunk_string, "%Y-%m-%d"), so any weekly auto-discovery PR that adds such a stanza will make the action crash for all workflows reading the matrix. This is especially likely because the current Splunk policy page uses dates like May 18 2028 rather than the comma format the scraper expects.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in commit a1a8a6e.
add_new_version_stanza now returns False immediately when get_supported_date returns UNKNOWN — no stanza is written, so the consumer's unconditional strptime can never receive an invalid value.
The skip condition was also tightened to eol_date <= today (i.e. reject on the EOL day itself) to align with main.py's today >= eol check. The test that previously asserted the stanza was added with SUPPORTED = UNKNOWN has been renamed and flipped to assert it is skipped; two new boundary-day tests were added.
…ated month format The page uses <td>X.Y</td><td>RELEASE</td><td>EOL</td> rows with dates formatted as "May 18 2028" (%b %d %Y), not full month names with a comma. The previous regex also captured the release-date column instead of the EOL-date column. Updated tests to use the real HTML table structure. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- add_new_version_stanza now returns False for UNKNOWN supported dates (main.py does an unconditional strptime, so UNKNOWN would crash the action) - Both add_new_version_stanza and remove_expired_versions now use <= today to match main.py's `today >= eol` semantics; on the exact EOL day the consumer already skips the stanza, so the pruner should remove it too - Renamed test to reflect the new behaviour (skips, not adds, on UNKNOWN) - Added boundary-day tests for both add_new_version_stanza and remove_expired_versions Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
P2 — Prune versions on their EOL date: addressed in commit a1a8a6e The boundary-date alignment has been fixed across the board:
This closes the one-day window where New tests added:
|
|
@codex please review |
These are internal planning artefacts and should not be part of the PR. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a1a8a6ec88
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if build: | ||
| config.set(major_minor, "BUILD", build) |
There was a problem hiding this comment.
Require BUILD before adding a new stanza
When Docker Hub exposes a version tag but the matching 12-character build tag is absent from the fetched tag list, this branch still writes a new [X.Y] section without BUILD. The runtime matrix generator later does props["build"] in _generate_supported_splunk, so the next released action using that generated config fails with a KeyError instead of just skipping or deferring that version. Please only add the stanza when a build was found, or provide a safe fallback.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in commit 30516e3.
add_new_version_stanza now returns False when get_build_number returns None — the stanza is only written when a build hash is found. BUILD is always set (the conditional if build branch was removed). A new test test_add_new_version_stanza_skips_when_no_build_hash covers this path.
| conf_path = tmp_path / "splunk_matrix.conf" | ||
| conf_path.write_text( | ||
| "[GENERAL]\nLATEST = 9.3\nOLDEST = 9.3\n" | ||
| "[9.3]\nVERSION = 9.3.10\nBUILD = aabbccddee00\nSUPPORTED = 2026-07-24\n" |
There was a problem hiding this comment.
Use a non-expiring fixture date
This fixture expires on 2026-07-24; beginning that day, update_splunk_version() will remove the [9.3] stanza via the new pruning step before the assertions that 9.3 remains and is OLDEST. That makes the test suite start failing solely because the calendar advanced, so this should use a dynamically future date.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in commit 30516e3.
The hardcoded SUPPORTED = 2026-07-24 date has been replaced with today + 10 years, computed at test runtime, so the pruner will never remove the 9.3 stanza as time advances. The integration test also gained a BUILD assertion for the new 10.4 stanza.
Runs tests/test_splunk_matrix_update.py on every PR and push. build_release now depends on both pre-commit and test passing. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…date - add_new_version_stanza now returns False when no build hash is found — main.py accesses props["build"] unconditionally, so a missing BUILD key would cause a KeyError at action runtime - Integration test SUPPORTED date changed to today+10y so the pruner never removes the 9.3 stanza as the calendar advances - Added test_add_new_version_stanza_skips_when_no_build_hash to cover the new guard; added BUILD assertion to integration test for new 10.4 stanza Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
A couple of review notes (non-blocking, but worth addressing): 1. Silent failure if the scrape breaks. The whole discovery path rests on 2. Auto-discovery will re-add deliberately-omitted versions. The config intentionally has |
If get_supported_date returns UNKNOWN for a newly discovered version the weekly workflow now fails visibly instead of silently skipping it. This ensures a broken lifecycle page scraper doesn't produce a quietly incomplete auto-discovery PR. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Thanks for the review. 1. Silent scrape failure — fixed in commit 1ae5672. 2. Re-adding deliberately-omitted versions — agreed this is intended behaviour: if a version gets a GA date it should be auto-added. I've added a note to the PR description so future reviewers of the weekly auto-PR aren't surprised by a reappearing stanza. |
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
🎉 This PR is included in version 3.2.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Summary
10.4,10.5) from Docker Hub and adds them toconfig/splunk_matrix.confUNKNOWNif unavailableSUPPORTEDdate has passed (UNKNOWNstanzas are never auto-removed)GENERAL.LATESTandGENERAL.OLDESTin sync with the actual version range10.4never accidentally matches10.40What changes
splunk_matrix_update.py— 6 new functions + updated orchestrator:get_all_major_minor_versionsX.Yprefixes from Docker Hub tagsget_new_versionsget_supported_dateadd_new_version_stanza[X.Y]stanzaremove_expired_versionsupdate_general_sectionLATEST/OLDESTrequirements-test.txt— new file;pytestmoved here fromrequirements.txtTest plan
config/splunk_matrix.confdiff in the weekly auto-PR to confirm new versions are picked up correctlySUPPORTED = UNKNOWNstanzas are not auto-prunedGENERAL.LATESTandGENERAL.OLDESTreflect actual version range after run🤖 Generated with Claude Code
Note on auto-discovery behaviour: versions that are currently in the Docker Hub tag list but have
SUPPORTED = Not Releasedon Splunk's lifecycle page (e.g.10.1) are skipped today because their EOL date is unknown. Once such a version receives a GA/EOL date it will be automatically added on the next weekly run. This is intentional — reviewers of future auto-PRs should expect to see previously-absent stanzas appear when Splunk publishes a new GA date.