CI/CD with GitHub Webhooks, Process Pull Request Events and Test Locally with JSON Payloads

Run CI/CD logic the moment a GitHub pull request opens, without polling and without waiting on a separate scheduler. This blueprint listens for GitHub pull request webhook events, extracts the pull request metadata from the payload, and posts an automated comment back to the PR through the GitHub REST API. The same flow can be replayed locally with a hand-supplied JSON payload, so you can develop and debug webhook-driven automation offline before it ever sees live traffic. It solves a common pain point: GitHub Actions and similar tools are hard to iterate on and troubleshoot because every change needs a real event to fire.

How it works

1. The io.kestra.plugin.core.trigger.Webhook trigger exposes a webhook endpoint secured by a key, and only fires when its io.kestra.plugin.core.condition.Expression condition confirms the pull request state is open and a comments_url is present.
2. The return task (io.kestra.plugin.core.debug.Return) resolves the GitHub comments URL using {{ trigger.body.pull_request.comments_url ?? inputs.payload.pull_request.comments_url }}, so it reads live webhook data in production and falls back to the payload JSON input during local runs.
3. The python_action task (io.kestra.plugin.scripts.python.Script) runs on a io.kestra.plugin.scripts.runner.docker.Docker task runner with the requests dependency and POSTs a comment back to the resolved URL, tagging it with {{ execution.id }} and {{ flow.id }}.

What you get

• Event-driven reaction to pull request activity with no cron or polling loop.
• Automated comments posted straight back to the originating GitHub PR.
• One flow that works both from real webhooks and from mock JSON inputs.
• Faster iteration: validate CI/CD logic locally before wiring up live events.

Who it's for

• Platform and DevOps engineers building GitOps and custom CI/CD pipelines.
• Backend teams who want observable, replayable pull request automation.
• Anyone frustrated by the slow edit-push-wait loop of traditional CI tools.

Why orchestrate this with Kestra

The Webhook trigger turns any GitHub event into a first-class execution, so reactions are immediate rather than scheduled. Each run is fully observable with retries, replays, and a complete execution history and lineage, which native CI runners rarely expose. The whole pipeline is declarative YAML you can version and review. The decisive gap GitHub's own automation cannot fill: you cannot easily replay a past event or run the exact same logic offline with a mock payload, whereas here the ?? fallback makes local testing trivial.

Prerequisites

• A Kestra instance reachable by GitHub's webhook delivery.
• A GitHub repository configured to send pull request webhooks to the trigger URL.
• Docker available for the Python task runner.

Secrets

• WEBHOOK_KEY: the secret key that authenticates the webhook endpoint.
• GITHUB_ACCESS_TOKEN: a GitHub token with permission to comment on pull requests.

Quick start

1. Add the WEBHOOK_KEY and GITHUB_ACCESS_TOKEN secrets to your Kestra instance.
2. Add the blueprint and copy the webhook URL exposed by the github trigger.
3. In your GitHub repo settings, add a webhook pointing at that URL for pull request events.
4. Open a pull request and watch the flow post an automated comment back.
5. To test offline, execute the flow manually and supply a sample JSON payload to the payload input.

How to extend

• Replace the comment body with status checks, labels, or reviewer assignments via the GitHub API.
• Add tasks to run tests, linters, or builds before commenting on the PR.
• Branch on trigger.body.action to handle opened, synchronized, or closed events differently.
• Fan out to Slack or email notifications alongside the GitHub comment.

Links

• Core plugin docs
• Python script plugin docs