Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[uss_qualifier] Add prod system version checking #532

Merged
merged 6 commits into from
Mar 7, 2024

Conversation

BenjaminPelletier
Copy link
Member

This PR fixes #467 by adding production/deployed system version checks to the F3548-21 test suite in the form of a new EvaluateSystemVersions scenario. The primary purpose of this scenario is to query production and test systems for their versions and compare those values. If more than one participant has a version mismatch, then the check fails (one participant can have a mismatch as this indicates they are testing a new software version). This scenario necessitates the provision of an additional resource specifying how to contact the production system to query its version.

An additional check is also added to look back through past version queries during the test run (if there are any, which there usually are for F3548-21) and makes sure the software version of the system under test didn't change during the test run.

@BenjaminPelletier BenjaminPelletier marked this pull request as ready for review March 7, 2024 07:09
self._test_env_version_providers = test_env_version_providers.version_providers
self._prod_env_version_providers = (
prod_env_version_providers.version_providers
if prod_env_version_providers
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I fully understand the impact of where the ? is in the yaml file. Won't this scenario be skipped with the current f3548_21.yaml file if prod_env_version_providers is not provided? Although there is a ? in the resources required by the suite, there is not in the resources required by the scenario.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this probably warrants more explicit documentation. In the resources section of a test suite definition, a ? means the resource is optional. That is, it's ok to run the test suite even if that resource isn't provided. In a test scenario declaration, it means roughly the same thing: the test scenario can be run even if that resource isn't provided.

When a resource is marked with a ? in a test scenario, the constructor of that scenario must have a default value for the resource (e.g., None). A test scenario in a test suite that can be run will be run. Therefore, if a test scenario wants resource X but resource X is not provided, then the test scenario will be run if X is marked with a ? in the test scenario declaration but not run if X is not marked with a ? in the test scenario declaration.

In this case, the version providers resource may or may not be provided to the test suite -- the test suite can still run effectively if it's not provided. But, if it's not provided, then the test scenario will be skipped entirely rather than trying to run it without that resource.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK I see thanks for the clarification.

In this case, the version providers resource may or may not be provided to the test suite -- the test suite can still run effectively if it's not provided. But, if it's not provided, then the test scenario will be skipped entirely rather than trying to run it without that resource.

Then, if the resource is missing, the scenario is skipped, doesn't that mean that prod_env_version_providers will always evaluate as truthy here? Or is it possible for a resource to exist but to be empty?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, right, sorry -- my mistake; this conditional was left over from when I actually did have the prod version providers as an optional resource earlier in development (it no longer is). Removed -- thanks for the catch

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah OK! Not that it's a big deal, but I felt like there was something I didn't get :)

@BenjaminPelletier BenjaminPelletier merged commit 817160d into interuss:main Mar 7, 2024
9 checks passed
@BenjaminPelletier BenjaminPelletier deleted the prod-version branch March 7, 2024 21:03
github-actions bot added a commit that referenced this pull request Mar 7, 2024
* Add prod system version checking

* Add note per comments

* Remove default value for non-optional parameter

* make format 817160d
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

GEN0305 uss_qualifier checks to verify ASTM F3548-21
2 participants