GitHub Action

The reusable Action runs a taskpack cycle in a consumer repository without a resident server. It discovers upstream changes, verifies candidates, and can publish a managed pull request.

Contents

• Workflow
• Execution and publication
• Secrets and environment
• Inputs
• Outputs
• Triggers

Workflow

Install a taskpack and configure the provider and App secrets before enabling this workflow. The App installation needs repository contents and pull request write permissions for native publication.

name: loopwright
on:
  schedule:
    - cron: '0 3 * * *'
  workflow_dispatch: {}
  issue_comment:
    types: [created]
permissions:
  contents: read
jobs:
  taskpack:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
          persist-credentials: false
      - uses: gpustack/loopwright@main
        id: loopwright
        with:
          taskpack-path: .loopwright/taskpack.yaml # Optional
          event-name: ${{ github.event_name }}
          event-path: ${{ github.event_path }}
          github-app-id: ${{ secrets.LOOPWRIGHT_APP_ID }}
          github-app-private-key: ${{ secrets.LOOPWRIGHT_APP_PRIVATE_KEY }}
          github-app-installation-id: ${{ secrets.LOOPWRIGHT_APP_INSTALLATION_ID }}
          output: json,github-step-summary # Optional
        env:
          ZAI_API_KEY: ${{ secrets.ZAI_API_KEY }}

• Taskpack: Set publication to pull_request to enable native PR publication, or disabled to omit it.
• Provider: Set the token variable for the selected model, not necessarily ZAI_API_KEY.
• Runtime: The Action sets up Node.js 26 and builds the workspace if its entrypoint is absent.
• Dry run: Set dry-run: 'true' to compile without running the controller.

Execution and publication

A live Action resolves repository identity and revisions, discovers upstreams, and looks for an existing managed PR. It compiles trusted artifacts outside the checkout, then runs the controller for admitted work.

Use upstream-records to supply precomputed acquisition records instead of live discovery. Matching upstream state can settle as no_change. Unavailable upstreams can block execution.

Native publication uses a detached git worktree, a signed-off diff-only commit, and --force-with-lease. It does not embed credentials in remote URLs. An uncertain external outcome remains unknown; do not silently retry it.

Local command.v1 checks run through a signed loopback gate against a verified candidate snapshot. The Action verifies each script digest and passes a limited environment. If a check opts into a GitHub token, it receives the resolved token; grant that token only the permissions the check may use.

On GitHub Actions, an omitted spec.sandbox selects direct-dedicated. This uses host process isolation, not a container security boundary. The turnkey host session supports macos-seatbelt, linux-bwrap, linux-landlock, and direct-dedicated, and blocks docker. See Sandbox Backends for isolation tradeoffs.

Protected paths override writable paths. Workflow files and taskpack control assets remain protected. See Taskpack for scope, instructions, and check configuration.

Secrets and environment

Pass a token with github-token, or provide all three App inputs to mint an installation token inside the Action. A nonempty github-token takes precedence, followed by GITHUB_TOKEN; either prevents App token minting. GH_TOKEN is not the Action token fallback.

The App ID and installation ID must be positive integers. The private key is a PEM secret. Restrict installation access to the target repository and required permissions. App tokens can trigger downstream workflows under GitHub’s App event rules.

Local command gates and native publication use ephemeral loopback credentials. They do not require external endpoint signing secrets. Generated registry and controller files contain secret references, not raw credentials. Never commit secrets to the repository.

Inputs

All Action inputs are optional. Conditional credentials, endpoint bindings, and event payloads depend on the taskpack and trigger.

Limit overrides apply in strict order (INPUT_* > LOOPWRIGHT_* > spec.limits > compiler defaults). Additional byte and session ceilings (LOOPWRIGHT_RESPONSE_BYTES, LOOPWRIGHT_TOOL_RESULT_BYTES, LOOPWRIGHT_FILE_BYTES, LOOPWRIGHT_SESSION_BYTES) also accept environment overrides. Interactive OAuth and CLI providers or MCP servers are unsupported. Model and MCP options are listed in Taskpack .

Outputs

The Action writes a compact, scrubbed result JSON summary (with SHA-256 digests and byte lengths rather than raw binary buffers) to stdout and GITHUB_OUTPUT. Live runs stream [loopwright] progress lines (upstream discovery, connected MCP servers, per-turn token/duration metrics, tool calls, and check outcomes) plus a plain-text run summary to stderr. A compiled result alone does not establish successful publication; inspect delegateOutcome and the run report.

Extended outputs are written for live runs, or for dry runs with an explicit output input. Step summaries and human-readable reports format token counts using K/M/B and elapsed durations using ms/s/m/h, while total-tokens and JSON reports preserve exact integer counts. Estimated cost uses model pricing and is not provider-attested billing. A missing cost is unknown, not zero.

totalTokens is the primary usage metric across sinks, with inputTokens and outputTokens breakdowns when available. Human-readable summaries show cost only for reported or estimated provenance. Reports include usage provenance when available. Output is scrubbed and workflow command text is neutralized. Local and fixture tests do not qualify live GitHub publication or provider billing.

Triggers

Intake supports schedule, manual dispatch, repository dispatch, release, issue comment, and pull request review events, subject to taskpack policy. Pass the event name and payload explicitly as shown above. Comment commands also require actor authorization.

Install a workflow in each consumer repository. For centralized webhook intake and token brokering, see GitHub App .