QA checks too onerous

[anton-seaice]

The QA checks for dev- configuration branches are too onerous for configurations at an alpha / preliminary development stage.

For example:

• we do not want runlog on, because it's leads to too many erroneous commits getting pushed to github which then need fixing
• the restart_freq feature for restart pruning in payu is not implemented yet, so it doesn't make sense to check that restart_freq is date based
• there is no reference available to go in metadata.yaml

For now, we can turn off these checks here and turn them on again when we create release- branches. Its also worth following up about having less strenous checks for dev branches compared to release branches.

( There github workflow which runs these tests intermittently gives false positives - see ACCESS-NRI/model-config-tests#92. This has by luck meant the current configs exist which failing the requirements of the QA checks).

[anton-seaice]

@aidanheerdegen asked:

If you think some of the config tests are still useful we could add other markers to enable them to be separated, or split the ones that are definitely for a stable released config into another set entirely.

There is already an access-om3 marker for qa tests, so I think the marker option exists.

I think we should only run the qa tests on release- branches, which we could achieve by removing dev- branches from on.pull_request triggers ? This could be done on only this repo by the looks.

This would however preclude the (future) option of any qa tests which run on dev- branches. To support a subset of qa tests to be run on dev- branches would probably need support for different pytest markers to be run on release- and dev- branches? This looks like it would need a change to the reusable workflow.

(FYI @CodeGat )

[anton-seaice]

ACCESS-NRI/model-config-tests#103 adds a "dev_config" marker we can use now for qa checks on dev branches