Run a Met from GitHub Actions

Put a Met inside your pipeline — summarize a deploy, review a change, run a task — with the exit code reflecting the result.

The CLI covers the same API as the SDK, so anything your backend does a CI step can do too. This recipe runs a Met when something happens in the repository, and makes the pipeline fail if the task failed.

Before you start

Store two secrets in the repository (Settings → Secrets and variables → Actions):

The CLI reads both environment variables directly, so there's no met config set in CI.

1. A Met that summarizes what just shipped

name: Deploy summary

on:
  push:
    branches: [main]

jobs:
  summarize:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 20

      - run: npm i -g @meteor.ia/cli

      - name: Summarize the pushed commits
        env:
          MET_API_KEY: ${{ secrets.MET_API_KEY }}
          MET_WORKSPACE: ${{ secrets.MET_WORKSPACE }}
        run: |
          COMMITS=$(git log --format='%s' -20)
          met run "Summarize these commits for the support team, in three bullets: $COMMITS" \
            --json --no-stream > output.json
          jq -r '.output' output.json >> "$GITHUB_STEP_SUMMARY"

--json prints the whole run on one line, ready for jq. --no-stream is what makes it usable in CI: without it the CLI paints the answer as it arrives, and what ends up in the log is fragments rather than parseable JSON.

2. A task that can fail the pipeline

met run executes a standalone Met. For a procedure with steps — the normal case when the result matters — use a task, and --wait to hold for the final state:

      - name: Pre-release review
        env:
          MET_API_KEY: ${{ secrets.MET_API_KEY }}
          MET_WORKSPACE: ${{ secrets.MET_WORKSPACE }}
        run: met tasks run tsk_123 --wait

With --wait, the exit code reflects the execution's final state: if the task fails, the step fails and the pipeline stops. Without --wait, the command fires the execution and returns immediately with a 0 that only means it started.

One thing to watch: if the task has a step that waits for someone's approval, --wait sits there until a person decides, and in CI that's a job hanging until the timeout. Tasks that run unattended shouldn't carry human pauses — see the approval recipe for when they're worth having.

3. A look at what went wrong

Useful as a final step when something failed, or as a scheduled job:

met runs list --status failed --limit 20

Energy is consumed all the same

A run from CI costs the same as one from your backend, and a workflow that fires on every push adds up fast. Two things help: use a separate key for CI, and give it a budget — subscribe to billing.threshold and you get a heads-up at 50, 80 and 100% instead of a surprise. Per-key consumption is in your dashboard under Developers.

Next

• Every command, the configuration and the output formats: CLI (met).
• To react when the run ends rather than waiting inside the job: receive signed events.