Currently there are a few use case that are not run in GitHub Actions for various reasons, like they exceed the memory limit or disk space limit. Some of these are noted in the Contributor's Guide. As part of the release process, we should make sure to run these use cases outside of the GitHub Actions automated testing environment to ensure that they run as expected.

The Contributor's Guide describes the process to add use cases that can't be run by not assigning a number to the use case in the internal/tests/use_cases/all_use_cases.txt file and excluding them from the .github/parm/use_case_groups.json file that determines the groups of use cases to run in the automated tests. We have since added support for a "disabled" key in the use_case_groups.json file to always skip those use cases.

There are a few use cases that are not run in the automated tests, but the reason is unclear because they are not listed in the Contributor's Guide section. This could happen for various external reasons (unrelated to GitHub Actions limitations) and we may be planning on eventually getting these cases working again.

Describe the Task

• Update the documentation and process for adding use cases that can't be run in GHA to:
  • Assign a number
  • Mark them as disabled in the JSON use case groups file
  • Add a reason why it is disabled for internal reference so we know if it will never be able to run in GHA or not
• Develop a process to run the use cases that can be run outside of GHA and run them to test that they work (on seneca?)
• Document process to run the cases and see if this step can be scripted to make this testing easier for future releases

Time Estimate

This depends on how much of this work we want to complete for this release and which should move to another issue for future work. We should at very least test the use cases that need to be tested!

Sub-Issues

Consider breaking the task down into sub-issues.

• Add a checkbox for each sub-issue here.

Relevant Deadlines

List relevant project deadlines here or state NONE.

Funding Source

Define the source of funding and account keys here or state NONE.

Define the Metadata

Assignee

• Select engineer(s) or no engineer required
• Select scientist(s) or no scientist required

Labels

• Review default alert labels
• Select component(s)
• Select priority
• Select requestor(s)

Milestone and Projects

• Select Milestone as a METplus-Wrappers-X.Y.Z version, Consider for Next Release, or Backlog of Development Ideas
• For a METplus-Wrappers-X.Y.Z version, select the METplus-Wrappers-X.Y.Z Development project

Define Related Issue(s)

Consider the impact to the other METplus components.

• METplus, MET, METdataio, METviewer, METexpress, METcalcpy, METplotpy

Task Checklist

See the METplus Workflow for details.

• Complete the issue definition above, including the Time Estimate and Funding Source.
• Fork this repository or create a branch of develop.
  Branch name: feature_<Issue Number>_<Description>
• Complete the development and test your changes.
• Add/update log messages for easier debugging.
• Add/update unit tests.
• Add/update documentation.
• Add any new Python packages to the METplus Components Python Requirements table.
• For any new datasets, an entry to the METplus Verification Datasets Guide.
• Push local changes to GitHub.
• Submit a pull request to merge into develop.
  Pull request: feature <Issue Number> <Description>
• Define the pull request metadata, as permissions allow.
  Select: Reviewer(s) and Development issue
  Select: Milestone as the next official version
  Select: METplus-Wrappers-X.Y.Z Development project for development toward the next official release
• Iterate until the reviewer(s) accept and merge your changes.
• Delete your fork or branch.
• Close this issue.