Skip to content


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.


Here is a simple workflow:

  name: Test Inception
  - report1
  - report2
  - report3
    runs-on: inception
    - uses: actions/prepare-inception@v1
        report.html: ${{ resources.files.report1 }}
        output.xml: ${{ resources.files.report2 }}
        log.html: ${{ resources.files.report3 }}
    runs-on: inception
    needs: [prepare]
      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:

curl -X POST \
     -H "Authorization: Bearer ${TOKEN}" \
     -F workflow=@workflow.yaml \
     -F report1=@report1.html \
     -F report2=@report2.xml \
     -F report3=@report3.xml \
curl -X POST ^
     -H "Authorization: Bearer %TOKEN%" ^
     -F workflow=@workflow.yaml ^
     -F report1=@report1.html ^
     -F report2=@report2.xml ^
     -F report3=@report3.xml ^
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' `

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.]


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.