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 theinception
tag. This differs from the usual channel plugins: they only acceptExecutionCommand
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 theExecutionResult
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.