[Static Validation] Pester structural tests

[AlexanderSehr]

Description

• Added tests for pipelines to the Pester test file
• Added documentation to configure the new settings

Pipeline

Type of Change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update (Wiki)

[github-actions]

Unit Test Results

  1 files  1 suites   11s ⏱️
  4 tests 4 ✔️   0 💤 0 ❌
38 runs  4 ✔️ 34 💤 0 ❌

Results for commit 6081fff.

♻️ This comment has been updated with latest results.

[eriqua]

I'd strongly suggest to avoid asking for another setting to customize. The majority of consumers, if not all, will use only one approach between ADO and GH.

What about adding the logic in the test itself, to run the ADO and/or the GH tests only if respectively the .azuredevops and/or the .github folders exist? That way we could remove the additional parameters from the settings.json and corresponding wiki instructions.

Instead, in the wiki, under the static validation, we should specify one sentence or two about the new test.

[AlexanderSehr]

I'd strongly suggest to avoid asking for another setting to customize. The majority of consumers, if not all, will use only one approach between ADO and GH.

What about adding the logic in the test itself, to run the ADO and/or the GH tests only if respectively the .azuredevops and/or the .github folders exist? That way we could remove the additional parameters from the settings.json and corresponding wiki instructions.

Instead, in the wiki, under the static validation, we should specify one sentence or two about the new test.

done

[MariusStorhaug]

Looks good, though the changes added here will only run if a workflow file exists for a module, correct? The idea with the issue that triggered this PR was to add a global pipeline/workflow to check a module compliance without having to rely on pipeline/workflow files existing for a module. I encountered many times that there exist a workflow file, but no pipeline file. That use case would be covered here, just thinking that it should be independent of the module-workflow running. It could basically be a status check/validation pipeline triggering on PR if so. i.e. if the contribution matching the "desired module design".

[AlexanderSehr]

Looks good, though the changes added here will only run if a workflow file exists for a module, correct? The idea with the issue that triggered this PR was to add a global pipeline/workflow to check a module compliance without having to rely on pipeline/workflow files existing for a module. I encountered many times that there exist a workflow file, but no pipeline file. That use case would be covered here, just thinking that it should be independent of the module-workflow running. It could basically be a status check/validation pipeline triggering on PR if so. i.e. if the contribution matching the "desired module design".

@MariusStorhaug Almost. If only checks if a Github or Azure DevOps folder exists respectively. Quite an important detail, as customers will only use one or the other

[eriqua]

🆗