Skip to content

v0.6.0 — Filter notifications by conclusion

Latest

Choose a tag to compare

@waleedkadous waleedkadous released this 18 Apr 07:08
· 1 commit to main since this release
4cf6b6b

What's new

New `--conclusions` flag filters notifications by CI run outcome. The channel is marketed as a failure alerter, and it now behaves that way.

Breaking change

Successful runs are no longer forwarded by default. The default filter drops:

  • Terminal non-failures: `success`, `skipped`, `neutral`, `manual`, `stale`
  • In-progress / non-terminal: `requested`, `in_progress`, `completed`, `running`, `pending`, `queued`, `waiting`, `preparing`
  • GitLab-specific non-terminal: `created`, `waiting_for_resource`, `scheduled`

Everything else is forwarded — including `failure`, `cancelled`, `timed_out`, `action_required`, and any unknown values (fail-open so new forge states aren't silently lost).

Restore previous behavior

Add to your `.mcp.json`:

```json
"args": ["tsx", "server.ts", "--conclusions", "all"]
```

Or filter to a specific set:

```json
"args": ["tsx", "server.ts", "--conclusions", "failure,cancelled"]
```

Multi-forge support

Normalization handles naming divergence across forges:

  • GitHub / Gitea use `failure` / `cancelled`
  • GitLab uses `failed` / `canceled`

Both resolve to the same canonical values before the filter check.


Closes #13. PR #14.