Inception

Sometimes, you do not want to run tests, but you want to test your plugins or, well, tests, or some parts of them.

The orchestrator comes with a special execution environment, inception, that you can use for this purpose.

Quickstart

Here is a simple workflow:

metadata:
  name: Test Inception
resources:
  files:
  - report1
  - report2
  - report3
jobs:
  prepare:
    runs-on: inception
    steps:
    - uses: actions/prepare-inception@v1
      with:
        report.html: ${{ resources.files.report1 }}
        output.xml: ${{ resources.files.report2 }}
        log.html: ${{ resources.files.report3 }}
  robot:
    runs-on: inception
    needs: [prepare]
    generator: tm.squashtest.org/tm.generator@v1
    with:
      squashTMUrl: https://squashtm.example.com/squash
      squashTMAutomatedServerLogin: ${{ variables.SQUASH_USER }}
      squashTMAutomatedServerPassword: ${{ variables.SQUASH_PASSWORD }}
      testPlanUuid: ...
      testPlanType: ...

A few new things. First, a new files section in the resources part lists the expected external inputs. Second, a preparation job uses a new function, actions/prepare-inception@v1. Finally, an almost unchanged generator job with two prerequisites: it targets the inception execution environment and needs the preparation job.

And that is about it.

Assuming the above is in a workflow.yaml file, you can then run your workflow the usual way:

BashCMDPowerShell

curl -X POST \
     -H "Authorization: Bearer ${TOKEN}" \
     -F workflow=@workflow.yaml \
     -F report1=@report1.html \
     -F report2=@report2.xml \
     -F report3=@report3.xml \
     -F variables="SQUASH_USER=${USER}\nSQUASH_PASSWORD=${PASSWD}" \
     https://orchestrator.example.com/workflows

curl -X POST ^
     -H "Authorization: Bearer %TOKEN%" ^
     -F workflow=@workflow.yaml ^
     -F report1=@report1.html ^
     -F report2=@report2.xml ^
     -F report3=@report3.xml ^
     -F variables="SQUASH_USER=%USER%\nSQUASH_PASSWORD=%PASSWD%" ^
     https://orchestrator.example.com/workflows

curl.exe -X POST `
     -H "Authorization: Bearer $Env:TOKEN" `
     -F workflow='@workflow.yaml' `
     -F report1='@report1.html' `
     -F report2='@report2.xml' `
     -F report3='@report3.xml' `
     -F variables="SQUASH_USER=$Env:USER`nSQUASH_PASSWORD=$Env:PASSWD" `
     https://orchestrator.example.com/workflows

That part is new, too. You can now send more complex requests to the receptionist service.

What does it do?

The inception execution environment does the following things:

• It accepts all ExecutionCommand requests, as long as they carry the inception tag. This differs from the usual channel plugins: they only accept ExecutionCommand requests that they can fully satisfy.

• It does not execute the ExecutionCommand statements. It always returns a success status. In the But it catches the ::attach:: workflow commands and attached the prepared files to the ExecutionResult it publishes.

• It outputs the commands it receives.

[If you were to have another execution environment that provides that inception tag, which would be a very bad idea, and if the arranger decides to send the ExecutionCommand to that environment, you would get the usual behavior, not the one described here.]

Limitations

There can be any number of workflows that may use it at any given time, but, for a given workflow, it cannot be used in parallel.

If the ::attach:: workflow commands are the result of environment-side execution, they will not be correctly caught if they are complex or guarded.