Skip to content

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:

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.