Skip to main content

Automated Execution

The project-level Settings → Automated Execution page holds the project's execution targets: the CI workflows, pipelines or webhooks a test run's automated cases can be sent to. See Automated Execution for the step-by-step setup guides per CI system and for how a dispatched job reads its plan and reports back.

note

Only system administrators and project administrators can open this page. Repositories are registered globally by a system administrator under Administration → Code Repositories; a target picks one of them.

How to access​

  1. Open the project.
  2. In the project menu, expand Settings and choose Automated Execution.

Adding a target​

Click Add target and choose a Provider:

  • GitHub Actions — pick a registered GitHub repository, then a workflow file. The workflow must have a workflow_dispatch trigger that declares the TESTPLANIT_* inputs. Choose the branch runs start on (the repository's default branch unless changed).
  • GitLab CI — pick a registered GitLab repository and the branch. TestPlanIt sends its parameters as pipeline variables.
  • Generic webhook — enter the URL TestPlanIt should POST to. A signing secret is generated when the target is saved and shown once; the page shows the payload the receiver gets.

Every provider takes:

  • Name — how the target appears on the run page.

  • Workflow inputs (GitHub), Pipeline variables (GitLab) or Variables (generic webhook) — static values sent with every dispatch in addition to the TESTPLANIT_* parameters. They are not secret. On GitHub each one must also be declared under workflow_dispatch.inputs.

  • Parameters — values the person executing a run chooses in the Execute automated cases dialog, so one target and one CI job can serve several browsers, environments or devices. Each parameter has an Input name (the key the job receives, same rules as a static input), a Label shown in the dialog, and a Type:

    • Single choice — a list of values and a default; the dialog shows a drop-down.
    • Multiple choice — a list of values and a default selection; the chosen values are sent as one comma-separated string (chrome,edge), so a value cannot itself contain a comma.
    • Text — free text with an optional default.
    • Configuration — one of the configurations assigned to the project (or several, with Allow choosing more than one), with an optional default. The dialog lists the project's enabled configurations by name. The job receives the choice as three inputs, so it can act on whichever it prefers: <name>_ID (the configuration id, 12 or 12,15), <name> (the configuration name, comma-separated when several) and <name>_VARIANTS (each configuration's variants as Category=Variant pairs, comma-separated, with several configurations separated by ;, for example Browser=Chrome,OS=Windows 11;Browser=Safari,OS=macOS). A configuration that is later unassigned or disabled is no longer offered, and an execution naming it is refused.

    Every parameter is sent on every dispatch, with its default when the dispatcher leaves it alone. An input name cannot start with TESTPLANIT_, cannot repeat within the target, and cannot match one of the target's static inputs; a configuration parameter also reserves its _ID and _VARIANTS names. Static inputs and parameters together are limited to 20 inputs, a configuration parameter counting as three. On GitHub each parameter (all three inputs of a configuration parameter) must also be declared under workflow_dispatch.inputs.

  • Timeout — minutes after which an unfinished execution is marked timed out (default 120).

  • Credentials — GitHub and GitLab targets use the repository's stored credential unless a different token is entered for dispatch. Starting a job needs the workflow scope on GitHub or the api scope (or a pipeline trigger token) on GitLab, which a repository registered for reading files may not have.

Managing targets​

  • Enabled turns a target on or off without deleting it. Disabled targets do not appear on the run page.
  • Verify checks that the credential works, the workflow exists and declares the expected inputs, and notes anything that would make a dispatch fail. The result is kept on the card.
  • Edit changes any field. For a generic target, Generate a new signing secret rotates the secret and reveals the new one once.
  • Delete removes the target. Past executions keep their history.