The XTrigger plugin makes it possible to monitor different environments (filesystem, jobs result, url response, binary repository and so on) and triggers a build if there is at least one change between two checks.
The plugin is intended to dev, QA and Ops users.

Features

The plug-in provides an aggregation of the following plugins for the Jenkins update center:

If you download and install the XTrigger from the update center, all the above plugins will be downloaded and installed automatically.
Additionally, all these plugins will be displayed in the log at startup.

Use cases

A pipeline

A first Jenkins job monitors developers commits from a SCM. A new build (application build + unit tests) is scheduled if changes are detected. The first job produces build outputs (logs, artifacts stored in repository and so on).
Note: This job can be also detected by a trigger stored in the SCM (if the chosen SCM provides this feature).

A second job monitors these build outputs and the job is scheduled if changes are detected between 2 checks.
Note: In the below diagram, build outputs are stored in a file-system. However, you can use any kind of resources. XTrigger plugin enables you to configure a poll for any kind of environment.

This configuration makes it possible to avoid having an hard-coded dependency between Jenkins jobs (upstream and downstream jobs).
The second job is scheduled by a condition applied to an external resource (filesystem, build results, url response, ...)

On development phase, you want to retrieve a recent version (often the last) and build (compile+test) your applications with these latest components versions.

Solution:
You often share between you and them, a binary repository (managed for example by one of the following tools: Sonatype Nexus, JFrog Artifactory, Apache Archiva, ...).

XTrigger plugin enables you to trigger jobs when a dependency library in the binary repository has changed
In the Java world, dependency management can expressed for example with Ivy or Maven.

Example

Sub-contractors develop and share a component A

You develop an application B. And B has dependency on A at compile time.

In your dependency management descriptor of B, you express that you want the latest version of a branch
(e.g. in Maven: e.g. 2.0-SNAPSHOT and in Ivy 2.+ or the latest from a status)

Sub-contractors push their new versions

Your Jenkins infrastructure with your dedicated job on B poll if there are new versions of A in the shared binary repository.

Note: In the above use case, your Jenkins instances are not shared: you have a dedicated Jenkins instance and sub-contractors can have their
Jenkins instances.
Note: XTRigger provides also a typology through the buildresult-trigger plugin (aka Job trigger) to achieve the same thing in the case you have a shared Jenkins instance).

Release 0.2

Release 0.1

2 Comments

Jenkins has time-based triggers and up/downstream triggers. I'm in need of a build trigger that combines these: e.g. trigger a build at midnight only if an upstream build was triggered in the past 24 hours. Could this be a possible extension for XTrigger?