Skip to main content
This example demonstrates Fliiq’s webhook triggers, safety gates, and multi-repo coordination — a release pipeline that Fliiq uses to manage its own releases. When code lands on main, Fliiq bumps the version, runs tests, publishes to PyPI, syncs public repos, and sends a Telegram summary.

​
The Setup

The Fliiq team wanted fully automated releases triggered by git push. They told Fliiq: 
"Set up a release pipeline that fires on every push to main. It should
bump the version, run tests, publish to PyPI, sync the public repo and
docs site, and send me a summary on Telegram. If tests fail, stop
everything and tell me what broke."

​
What Fliiq Created

The agent called create_job with a webhook trigger: 
name: release-pipeline
trigger:
  type: webhook
  source: git-push
  match:
    branch: main
prompt: |
  A push to main just landed. Here are the commits:

  {{commits}}

  Execute this release pipeline in order. If any safety gate fails,
  STOP and report the failure via Telegram — do not publish a broken release.

  ## Step 1: Version Bump
  - Read current version from pyproject.toml
  - Analyze the commits to determine increment type:
    - patch (X.Y.Z+1): bug fixes, small tweaks, doc updates
    - minor (X.Y+1.0): new features, new skills, new CLI commands
    - major (X+1.0.0): breaking changes to CLI, job schema, or skill API
  - Update the version string in pyproject.toml

  ## Step 2: README Maintenance
  - If commits warrant README updates (new features, changed CLI): update
  - If not: skip — don't touch README for the sake of touching it

  ## Step 3: Commit, Test, Build, Publish
  - Stage and commit: "release: vX.Y.Z"
  - SAFETY GATES (both must pass before publishing):
    1. pytest tests/ -q
    2. ruff check src/
  - If gates pass: build and publish to PyPI
  - If either fails: STOP HERE. Do not build or publish.

  ## Step 4: Sync Public Repo
  - Copy README.md to public repo
  - Add CHANGELOG.md entry for this version
  - Commit and push

  ## Step 5: Update Developer Docs
  - If new features need documenting, update relevant docs
  - If no doc changes needed, skip

  ## Step 6: Telegram Summary
  - Version number and bump type
  - What changed (1-3 bullet points)
  - PyPI status: published or failed
  - Public repo: synced or failed
  - Docs: updated or skipped
skills:
  - shell
  - read_file
  - write_file
  - edit_file
  - list_directory
  - grep
  - find
  - send_telegram
  - memory_read
  - memory_write
  - get_current_time
delivery:
  type: telegram
  chat_id: "12345678"
enabled: true

​
How It Works — A Real Release

​
Run 1: Safety Gate Catches Lint Errors

A developer pushes a commit bumping the default Anthropic model. The webhook fires and Fliiq starts the pipeline:
  1. Version bump: 1.7.2 → 1.7.3 (patch — dependency update)
  2. pytest: 517 passed — gate cleared
  3. ruff: 61 errors found — pipeline halted
Fliiq refused to publish and sent this Telegram message: 
❌ Pipeline halted — v1.7.3

✅ pytest: 517 passed
❌ ruff: 61 errors — pipeline stopped

To unblock:
1. ruff check src/ --fix — auto-fixes 38 of 61
2. Manual fixes for remaining 23 (long lines, bare except,
   unused imports)
3. Re-run the pipeline
Duration: 73 seconds. The pipeline analyzed commits, bumped the version, ran the full test suite, caught the lint issues, and delivered a detailed failure report — all automatically.

​
Run 2: Clean Release

The lint errors are fixed and pushed. The webhook fires again:
  1. Version bump: Already at 1.7.3 — no change needed
  2. Safety gates: Both passed
    • pytest: 517 passed, 6 warnings
    • ruff: 0 errors
  3. PyPI: Published → https://pypi.org/project/fliiq/1.7.3/
  4. Public repo: README synced, CHANGELOG updated with v1.7.2 and v1.7.3 entries
  5. Docs: Skipped — no user-facing feature changes
  6. Telegram: Summary sent
✅ v1.7.3 — Released Successfully

• Safety gates: pytest ✅ (517 passed) | ruff ✅ (0 errors)
• PyPI: Published → pypi.org/project/fliiq/1.7.3/
• Public repo: README synced, CHANGELOG updated
• Docs: Skipped — no user-facing changes

Suggested: pyproject.toml license field uses deprecated
syntax — worth updating before next release.
Duration: 2 minutes. Version analysis, full test suite, package build, PyPI upload, cross-repo sync, and Telegram notification — zero human intervention.

​
Adapting for Your Projects

The release pipeline pattern works for any project. Here’s a minimal version: 
name: my-release
trigger:
  type: webhook
  source: git-push
  match:
    branch: main
prompt: |
  New commits on main: {{commits}}

  1. Bump version in package.json based on commit content
  2. Run: npm test
  3. If tests pass: npm publish
  4. Send summary to Telegram
skills:
  - shell
  - read_file
  - edit_file
  - send_telegram
delivery:
  type: telegram
  chat_id: "YOUR_CHAT_ID"
enabled: true
Or a manual trigger you run when you’re ready to release: 
fliiq job run my-release

​
Managing the Pipeline

fliiq job list                            # See status and last run
fliiq job logs release-pipeline           # View run history
fliiq job output release-pipeline         # Full output from last run
fliiq job run release-pipeline            # Manual trigger

​
The Key Insight

Traditional CI/CD pipelines are rigid — a fixed sequence of shell commands that either pass or fail. Fliiq’s release pipeline is intelligent: it analyzes commit content to decide the version bump, determines whether docs need updating, and when something fails, it doesn’t just exit with code 1 — it diagnoses the problem, suggests fixes, and delivers an actionable report. The safety gate pattern is critical: the pipeline has the authority to build and publish, but mandatory checks prevent it from shipping broken code. Trust but verify. This is the same pipeline Fliiq uses to release itself. Every version on PyPI was published by this job.