For .github/workflows/module_acceptance.yml, can we have a version which does not hardcoded to all the Litmus Tasks? This makes it harder to update some of old modules, whose dependencies vary a lot.

[sooyean-hoo]

Use Case

For .github/workflows/module_acceptance.yml, can we have a version which does not hardcoded to all the Litmus Tasks? This makes it harder to update some of old modules, whose dependencies/implementation/styles vary a lot.

Describe the Solution You Would Like

Currently, These are what the acceptance tests hard-coded to perform the tests.

steps: 
  - description: 'Task for the step "Provision environment"'
     task: 'litmus:provision'
  - description: 'Task for the step  "Install Puppet agent"'
     task: 'litmus:install_agent'
  - description: 'Task for the step "Install module"'
     task: 'litmus:install_module'
  - description: 'Task for the step "Run acceptance tests"'
     task: 'litmus:acceptance:parallel'
  - description: 'Task for the step "Remove test environment"'
     task: 'litmus:tear_down'

The above is hardcoded, so developer has to work around these rake tasks. In another words, they have to twist and adapt the tests below the rake task levels: PDK levels and more. Sometimes, this is done with risk of breaking the currently stable and working rake tasks, which are running the acceptance tests.

Describe Alternatives You've Considered

Each steps can be set to call a rake task of the developer's choosing, but it is default to the litmus'.
In this way, it is easier to import/migrate modules into using these workflow. They just need to map their original scripts/steps into the one above, and expose them as rake tasks.

Also, if any of the original steps can be replaced easily with the litmus'. Moreover for those with some of the original steps which are using the same Litmus' tasks. These step can also form a kind of anchor in these workflow.

Since this will drive or ease developer into the new standard of acceptance workflow set-up here, passing/taking over of puppet modules' acceptance tests among developers would be intuitive.

Additional Context

Similar scenarios are at play in my fork of puppetlabs-servicenow_cmdb_integration @ puppetlabs-servicenow_cmdb_integration

[sooyean-hoo]

matrix_from_metadata should be also exposed as a variable too

[sooyean-hoo]

Done a version of it @ https://github.com/sooyean-hoo/cat-github-actions/blob/dev_sooyean/.github/workflows/module_acceptance_custom.yml

Successfully deploy and integrate and upgrade the test of module https://github.com/puppetlabs/puppetlabs-servicenow_cmdb_integration to follow the new .github/workflows/module_acceptance.yml as close as possible.

Runs... See https://github.com/sooyean-hoo/puppetlabs-servicenow_cmdb_integration/actions/runs/10669025799