Webhook icon
JobBuild icon
Sequential icon
Request icon
Assert icon
SlackIncomingWebhook icon

Event-Driven Jenkins Job with Slack Status Notification

Trigger Jenkins jobs from a Kestra webhook, poll the lastBuild API until the build is terminal, and notify Slack with the outcome automatically.

Categories
Infrastructure

Run Jenkins jobs as event-driven pipelines instead of cron-scheduled or manually launched builds. This blueprint lets any external system fire a Kestra webhook, which enqueues a Jenkins job with parameters pulled from the request body, waits for the build to actually finish, and reports the final result to Slack. It solves the classic CI gap: kicking off a Jenkins build is easy, but reliably knowing when it completed and reacting to the outcome inside a broader orchestration flow is not. By wrapping the build in Kestra you get a fire-and-wait pattern with retries, alerting, and full execution lineage.

How it works

  1. The on_event trigger (io.kestra.plugin.core.trigger.Webhook) exposes an HTTP endpoint guarded by a secret key. Any source can POST to it to start the flow.
  2. The enqueue_build task (io.kestra.plugin.jenkins.JobBuild) queues the Jenkins job named by the job_name input, passing a branch parameter from trigger.body.branch (defaulting to main) plus a triggered_by tag.
  3. The wait_for_completion task (io.kestra.plugin.core.flow.Sequential) wraps a poll loop with a constant retry of PT15S and maxAttempt: 80. Inside it, last_build (io.kestra.plugin.core.http.Request) calls the Jenkins lastBuild/api/json endpoint, and assert_terminal (io.kestra.plugin.core.execution.Assert) fails until result is non-empty, forcing another retry until the build reaches a terminal state.
  4. The notify task (io.kestra.plugin.slack.notifications.SlackIncomingWebhook) posts the final result and execution id to Slack.
  5. An errors handler (alert_on_failure) sends a separate Slack alert if any step fails.

What you get

  • On-demand Jenkins builds triggered by webhooks instead of waiting on Jenkins cron.
  • A true wait-for-completion barrier so downstream logic only runs after the build finishes.
  • Automatic Slack notifications for both success and failure paths.
  • Built-in retry and timeout ceiling (80 attempts at 15s is a 20-minute window).

Who it's for

  • Platform and DevOps engineers connecting Jenkins to event-driven workflows.
  • Release teams that want CI builds kicked off by deploys, merges, or external tools.
  • Data and infra teams orchestrating Jenkins alongside other pipeline steps.

Why orchestrate this with Kestra

Jenkins can schedule and run jobs, but it cannot natively wait on an external HTTP event, branch a larger pipeline on the build result, or guarantee retries and alerting across heterogeneous tools. Kestra adds an event trigger, declarative YAML, automatic retries on the polling block, failure alerting, and end-to-end execution lineage so a Jenkins build becomes one observable step in a wider orchestration rather than an isolated CI run.

Note on polling: JobBuild does not return the queued build number and JobInfo requires a known number, so polling lastBuild via core.http.Request is the working pattern until the plugin ships a native trigger-and-wait task.

Prerequisites

A reachable Jenkins instance, a job name, and a Slack incoming webhook.

Secrets

  • JENKINS_USERNAME: Jenkins user for Basic Auth.
  • JENKINS_API_TOKEN: Jenkins API token.
  • JENKINS_TRIGGER_KEY: key guarding the Kestra webhook trigger.
  • SLACK_WEBHOOK_URL: Slack incoming webhook URL.

Quick start

  1. Set the four secrets above in your Kestra namespace.
  2. Set the jenkins_url and job_name inputs for your instance.
  3. POST to the webhook URL with build parameters in the body (for example a branch field).
  4. Watch Slack for the outcome notification.

How to extend

  • Add an If task after wait_for_completion to branch on the result (SUCCESS, FAILURE, UNSTABLE, ABORTED).
  • For foldered jobs, set jenkins_url to the full folder path (for example https://jenkins.example.com/job/team/job/project) and jobName to the leaf only.
  • For high-concurrency jobs, capture lastBuild.number before enqueue and add a condition asserting the current number is greater, so polling never reads a sibling build.
  • Tighten or widen the retry interval and maxAttempt to match your build durations.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.