Frequent Workflow Use Cases

[ckunki]

Since version 6 PTB supports generating workflows from templates incl. patching them based on the contents of a file called .workflow-patcher.yml (see user guide). However, I could imagine some use cases I would rate as "frequent", to be supported in a bit more convenient or obvious way.

UC2-UC5 can probably be covered by supporting individual variants of GitHub workflow slow-checks.yml

• UC1: Different name of Sonar token SONARQUBE_GITHUB_SECRET Instead of SONAR_TOKEN) enabling private repositories to use Exasol's onprem Sonar service
• UC2: Allow unprivileged user namespaces for running Exasol UDFs on GitHub Runners with Apparmor restrictions, e.g. ubuntu-24.04.

  - name: Allow unprivileged user namespaces
    run: sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

• UC3: Free disk space
• UC4: Add additional pytest parameters e.g. --backend
• UC5: Add environment variables, e.g. SAAS_HOST

[ahsimb]

It's desirable that entire workflows could be added/replaced rather than a single job.

Use case:

The MCP Server repo has two separate slow test workflows instead of one - slow-checks-itde.yml and slow-checks-saas.yml. Like the standard slow-checks.yml, the are called from allow-merge.yml, where both of the jobs calling these workflows must be completed.

Also, there is an additional workflow - create-docker-image.yml called from the cd.yml

[ArBridgeman]

It's desirable that entire workflows could be added/replaced rather than a single job.

Use case:

The MCP Server repo has two separate slow test workflows instead of one - slow-checks-itde.yml and slow-checks-saas.yml. Like the standard slow-checks.yml, the are called from allow-merge.yml, where both of the jobs calling these workflows must be completed.

Also, there is an additional workflow - create-docker-image.yml called from the cd.yml

Something similar will be allowed with #730.