New to Kestra?
Use blueprints to kickstart your first workflows.
Trigger Jenkins jobs from a Kestra webhook, poll the lastBuild API until the build is terminal, and notify Slack with the outcome automatically.
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.
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.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.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.notify task (io.kestra.plugin.slack.notifications.SlackIncomingWebhook) posts the final result and execution id to Slack.errors handler (alert_on_failure) sends a separate Slack alert if any step fails.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.
A reachable Jenkins instance, a job name, and a Slack incoming webhook.
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.jenkins_url and job_name inputs for your instance.branch field).If task after wait_for_completion to branch on the result (SUCCESS, FAILURE, UNSTABLE, ABORTED).jenkins_url to the full folder path (for example https://jenkins.example.com/job/team/job/project) and jobName to the leaf only.lastBuild.number before enqueue and add a condition asserting the current number is greater, so polling never reads a sibling build.interval and maxAttempt to match your build durations.