SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillstestany-trigger

testany-trigger

General & other

View repository

Updated 10-16 08:11

About this skill

Testany Trigger

Manage on the Testany platform trigger, and is responsible for initiate a pipeline execution immediately。

User input: $ARGUMENTS

First unify the mental model

Follow overall goals and handoff. When the user requests one execution and waits for the terminal state, after obtaining the execution key continue with testany-execution, rather than stopping at successful startup; if only starting or configuring, stop at that goal.

Before starting, first follow automation-model.md to understand the boundaries:

  • pipeline is the execution and orchestration unit
  • trigger is the execution entry
  • trigger determines "how to initiate an execution"
  • execution observation and management after initiation belong to testany-execution

Key conclusions：

  • This skill is responsible for bothpersistent execution entries, and also forimmediate one-time triggering
  • This skill is not responsible for viewing execution history, polling, cancellation, or failure diagnosis
  • Configuring an execution entry does not automatically authorize Run Now; successful initiation does not equal successful execution; UI fallback does not equal configured

Scope of responsibility

Follow delivery verification read back the status related to this round of changes. Request acceptance, configuration consistency, execution submitted, and execution success are separate; on partial failure retain resources and the real key, and do not automatically delete, roll back, or retry.

  • Create/query/update/delete Plan (scheduled plan)
  • Create/query/update/delete Gatekeeper (Webhook trigger)
  • Cover the platform concepts, applicable scenarios, and currently supported paths of Manual Trigger
  • Execute an existing pipeline once immediately (ad-hoc run now)
  • Provide suitable trigger solution suggestions for existing pipelines
  • Provide copyable Webhook / CI integration examples

Trigger types

Persistent Trigger

Long-lived, repeatedly reusable execution entries:

  • Plan
  • Manual Trigger
  • Gatekeeper

Ad-hoc Trigger

One-time immediate trigger:

  • testany_execute_pipeline

It will directly return execution_key, and subsequent observation and management are handed over to testany-execution。

Current MCP support status

Type Platform capability Current MCP support How this skill handles it
Plan Complete Yes Directly via MCP CRUD
Gatekeeper Complete Yes (including pipeline binding and webhook URL) Complete the full flow directly via MCP
Manual Trigger Platform already supports No corresponding MCP tools currently seen Explicitly include in the trigger system; if the current host/MCP has no tools, guide the user to UI fallback
Run Now Complete Yes (testany_execute_pipeline) Directly execute once and return execution_key

Operations quick reference

Persistent Trigger

User intent Operation type MCP tool
List Gatekeepers Read testany_list_gatekeepers
View Gatekeeper details Read testany_get_gatekeeper
Create Gatekeeper Create testany_create_gatekeeper(can bind pipelines at the same time)
View Pipelines bound to a Gatekeeper Read testany_get_gatekeeper_pipelines
Bind/replace a Gatekeeper's Pipelines Update testany_bind_gatekeeper_pipelines
Update Gatekeeper fields Update testany_update_gatekeeper
Delete Gatekeeper Delete testany_delete_gatekeeper
List Plans Read testany_list_plans
View Plan details Read testany_get_plan
Create Plan Create testany_create_plan
Update Plan Update testany_update_plan
Delete Plan Delete testany_delete_plan
Transfer Plan Owner Update testany_assign_plan

Common helpers:

  • testany_get_my_workspaces
  • testany_list_pipelines

Ad-hoc Run Now

User intent MCP tool
Execute a pipeline once immediately testany_execute_pipeline

Trigger selection principles

Method Applicable scenarios
Plan Automatic execution at a fixed time, such as nightly regression or scheduled inspection
Manual Trigger Manual on-demand execution, such as retesting after a fix or acceptance before release
Gatekeeper Execution driven by external events, such as CI/CD, alerts, or Webhooks
Run Now Execute once right now without persisting a long-term trigger resource

Run Now (execute once immediately)

Applicable scenarios

  • "Run this pipeline once for me now"
  • "Run a one-off regression"
  • "I just finished the changes, verify immediately"

Process

  1. If the user does not have a clear pipeline key:
    • testany_get_my_workspaces
    • testany_list_pipelines
    • Help the user locate the target pipeline
  2. According to Execution permission and waiting contract check this round's execution permission, pipeline, environment/parameters, and side effects; do not repeatedly ask for information that is already clear, then call once testany_execute_pipeline
  3. Return execution_key
  4. Clearly tell the user:
    • Only say execution has been initiated when the tool confirms it has been accepted and returns a key; without terminal-state evidence, do not say the test succeeded
    • If you next need to view progress, check history, cancel, or view results, switch to testany-execution

Input supplements

If needed, you can also pass:

  • environment
  • parameters

But do not mistakenly write these one-off parameters as long-term trigger configuration.

Plan (scheduled plan)

Definition

Plan is used to automatically trigger one or more pipelines according to a fixed schedule.

Creation process

  1. testany_get_my_workspaces → Select workspace
  2. testany_list_pipelines → Select the pipelines to be executed on schedule
  3. testany_create_plan → Create plan
  4. testany_get_plan Verify the target, schedule, and configuration; if accepted but read-back fails, state that it has been created but not verified, and do not create it again

Recommended to also fill in:

  • schedule_expr
  • timezone
  • schedule_str
  • watchers

Update precautions

Plan updates should be treated as high-risk "overwrite-style updates":

  1. testany_get_plan First read the existing configuration
  2. Construct a complete payload based on the existing configuration
  3. Then call testany_update_plan
  4. Read back and verify this round's fields; if inconsistent or permissions are insufficient, report that verification is blocked, and do not automatically execute the plan to "verify the configuration"

Manual Trigger (on-demand execution template)

Definition

Manual Trigger is used to execute one or more pipelines on demand, without relying on scheduled triggering or external webhooks.

Typical scenarios

  • Quick regression before a hotfix release
  • Immediately retest critical paths after environment recovery
  • Manually initiate standardized multi-pipeline acceptance

Current handling method

If the current MCP/host does not have a Manual Trigger tool:

  1. Help the user determine the workspace and pipelines
  2. Provide suggested name, description, and pipeline list
  3. Prompt the user to create a Manual Trigger in the Testany UI
  4. Make it clear that it is "not yet configured, pending user action"; do not claim that MCP is complete, do not replace it with Plan/Gatekeeper/Run Now, and do not operate the UI without authorization

If the current host actually has the corresponding tool, configure it according to its real schema and read it back; do not infer from this table that the tool is permanently missing.

Gatekeeper (Webhook / event-driven)

Definition

Gatekeeper triggers the execution of a pipeline group via Webhook.

Important clarification

  • Gatekeeper is not a pipeline orchestration tool
  • Gatekeeper is not an execution observability tool
  • "Whether to allow deployment" belongs to external CI/CD logic and should be decided on your own based on the execution result after calling Gatekeeper

Creation flow

Method 1: Bind directly at creation time (recommended)

  1. testany_get_my_workspaces → Select workspace
  2. testany_list_pipelines → Select the pipelines to trigger
  3. testany_create_gatekeeper(workspace, name, pipelines=[...]) → Create and bind
  4. testany_get_gatekeeper → Obtain hook_url
  5. testany_update_gatekeeper → Configure trigger_method / trigger_name / trigger_condition / watchers / owned_by
    • Only set the fields required for this round; do not override default values just to complete the flow; do not call update when there is no additional field target
  6. Use testany_get_gatekeeper / testany_get_gatekeeper_pipelines to verify this configuration and binding; a read-back failure only means it has been created/submitted but verification is blocked

Method 2: Create first, then bind

  1. testany_create_gatekeeper → Create Gatekeeper
  2. testany_bind_gatekeeper_pipelines → Bind pipelines
  3. testany_get_gatekeeper_pipelines → Confirm the binding result

Obtaining the Webhook URL

By using testany_get_gatekeeper to get the details, you can obtain hook_url. If the user does not have edit permission,hook_url will be null.

CI/CD integration example

GitHub Actions

- name: Trigger Testany Gatekeeper
  run: |
    curl -X POST "${{ secrets.TESTANY_GATEKEEPER_WEBHOOK_URL }}" \
      -H "Content-Type: application/json" \
      -d '{"source":"github-actions"}'

Jenkins

stage('Quality Gate') {
    steps {
        sh '''
          curl -X POST "${TESTANY_GATEKEEPER_WEBHOOK_URL}" \
            -H "Content-Type: application/json" \
            -d '{"source":"jenkins"}'
        '''
    }
}

Return format

Report based on actual operations and evidence; do not use a uniform "MCP direct connection completed" template:

  • Trigger type:Plan / Manual Trigger / Gatekeeper / Run Now
  • List of target pipelines
  • Actual result: configured and verified / submitted but verification blocked / execution initiated / pending user action / operation failed
  • The object key, tool response, or read-back that supports this result; list partially completed and incomplete items, and do not hide subsequent failures because one step succeeded
  • Key configurations (schedule_expr, timezone, watchers, trigger_name, etc.); do not rename the platform's original enums
  • If it is Run Now:
    • Return execution_key
    • Based on the key alone, only claim that it has been initiated; if the user has requested waiting for the final state, continue testany-execution, do not wait on your own for a start request only, and any waiting does not authorize cancellation or retry
  • If it is Gatekeeper:
    • Return the Webhook URL (obtained via testany_get_gatekeeper; null when there is no permission)

Configuration read-back cannot prove that the test passed; when the response is uncertain, check the status first, and do not automatically retry creating or deleting the object to "roll back".

Reference documentation