Fix all tests - #599
Open
bastelfreak wants to merge 4 commits into
Open
Conversation
PRs #384/#385 removed the deprecated data_binding_terminus and environment_data_provider settings and the metadata.json data_provider key, as accepted in the OpenVox 9 deprecation review. Two acceptance tests still configured environment and module data through those removed mechanisms and began failing on all platforms once 9.0.0 beta packages were built (acceptance-pipelines run 31098859281). Migrate the fixtures the same way #385 migrated the in-repo spec fixtures: - tests/lookup/lookup.rb: bind the environment and module data functions through hiera.yaml (version 5, v4_data_hash) at the environment root and module roots; drop the data_provider key from metadata.json. - tests/parser_functions/puppet_lookup_cmd.rb: env2/env3 (function providers) get env-level hiera.yaml v5 with v4_data_hash: environment::data; env4 (none) gets an explicit empty hierarchy, since environments always have a data layer under Hiera 5; production/env1 keep their still-supported v4 env hiera.yaml. mod2/mod3 (function) get module hiera.yaml v5 with v4_data_hash; mod4 (none) loses its hiera.yaml entirely so the module layer is absent, preserving the not-found behavior the assertions expect. The inert environment_data_provider lines and all 20 metadata.json data_provider keys are removed. One --explain assertion is updated because the environment data provider section now always appears in explain output (previously absent under provider none). Verified on a local beaker rig (single almalinux 9 primary running openvox-agent 9.0.0~beta2 and openvox-server 9.0.0~beta4, the versions from the failing pipeline run): both pipeline failures reproduced exactly with the pristine tests, and both tests pass with this change. All lookup *value* expectations are unchanged -- the loader picks the same function implementations the v4 providers did (ruby when both ruby and puppet-language exist, e.g. env2/mod2; puppet-language when only it exists, e.g. env3/mod3) and the v4_data_hash backend even preserves the Deprecated API function explain wording the test asserts. Note for rerunning on persistent hosts: the puppet_lookup_cmd teardown removes node1/node2 SSL keys but not the CA-signed certs, so back-to-back runs against the same CA need a puppetserver ca clean first. Fresh pipeline VMs are unaffected. Signed-off-by: Steven Pritchard <steven.pritchard@gmail.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
ensure_puppet_facts_can_use_facter.rb asserted that the facterversion fact reported a major version of at most 5. Hardcoding the major version breaks on every openfact major bump -- openfact 6.0.0 shipped in openvox-agent 9.0.0~beta2 made the test fail on all 11 platforms in acceptance run 31098859281 (openvox-agent suite). Compare the fact against the output of facter --version on the agent instead, which expresses what the test actually cares about (puppet facts uses the bundled facter) and survives future major bumps. Verified on a local beaker rig against openvox-agent 9.0.0~beta2 (openfact 6.0.0): the unmodified test fails with the same Minitest assertion as the pipeline; with this change it passes. Signed-off-by: Steven Pritchard <steven.pritchard@gmail.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
openvox#583 changed the default of the reports setting from store to none, so the server now accepts report submissions and hands them to no processors. cached_catalog_remediate_local_drift.rb asserted that a submitted report appears under the server reportdir while relying on the old default, and began failing on all platforms in acceptance run 31098859281 (openvox suite, shard:group4). Diagnosis on a local rig confirmed the agent PUT succeeds (200 in the server access log) while nothing is stored. Set reports = store and a test-owned reportdir in master_opts, matching the pattern the other report-checking acceptance tests (reports/submission.rb, reports/cached_catalog_status_in_report.rb, direct_puppet/catalog_uuid_correlates_catalogs_with_reports.rb) already use -- this test was the only one relying on the default. Also fix the reversed assert_equal argument order in the two report-count assertions so failure messages report expected and actual correctly, and clean up the reportdir in teardown. Verified on a local beaker rig against openvox-agent 9.0.0~beta2 and openvox-server 9.0.0~beta4: the unmodified test reproduces the pipeline failure; with this change it passes. Note for release notes: the reports=none default change itself is user-visible (report YAML consumers must now set reports=store) and should be called out in the 9.0 release notes. Signed-off-by: Steven Pritchard <steven.pritchard@gmail.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
…tics openvox#170 removed the implicit filebucket retrieval for file content values that look like checksums; such content is now always managed literally. Two acceptance tests still exercised the removed behavior and fail on all platforms (acceptance run 31157133263, openvox suite shard:group3; also present but masked behind the lookup failures in run 31098859281): - ticket_6541_invalid_filebucket_files.rb asserted that checksum-like content never overwrites the target and that a well-formed checksum retrieves bucket content. Rewritten as a regression test for the new semantics: checksum-like content -- malformed or well-formed -- is written literally, which is exactly the capability whose absence motivated the removal. - resource/file/content_attribute.rb ended with a checksum-from-filebucket scenario; that block is removed with a comment pointing at the rewritten test. The raw-content, checksum-type, and illegal-timestamp coverage is unchanged. Verified on a local beaker rig against openvox-agent 9.0.0~beta2: both tests reproduce the pipeline failures unmodified and pass with this change. Signed-off-by: Steven Pritchard <steven.pritchard@gmail.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Contributor
|
2nd try after adding #602: https://github.com/OpenVoxProject/acceptance-pipelines/actions/runs/31190044925 |
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.
This is a combination of:
related acceptance tests: https://github.com/OpenVoxProject/acceptance-pipelines/actions/runs/31157133263