Child pages
  • ScriptTrigger Plugin
Skip to end of metadata
Go to start of metadata

Plugin Information

Distribution of this plugin has been suspended due to unresolved security vulnerabilities, see below.

The current version of this plugin may not be safe to use. Please review the following warnings before use:

This plugin is up for adoption. Want to help improve this plugin? Click here to learn more!

ScriptTrigger makes it possible to monitor an environment with a script.

Features

The ScriptTrigger plug-in enables you to configure the polling predicate by the evaluation of a script.

Two types of script are supported
* Groovy script
If the expression evaluation returns true, a build is scheduled.
* Shell or Windows Batch script
A script is executed and a build is scheduled if the exit code matches your expected exit code.

For both types, if the script execution output contains the content <cause>YOUR_SCHEDULED_CAUSE</cause>, 'YOUR_SCHEDULED_CAUSE' is used as the build cause.
Additionally, if the script execution output contains the content <description>MY DESCRIPTION</description>, the 'MY DESCRIPTION' value is attached to the run.

Note: The plug-in uses only persistence in memory. There is no impact on the Jenkins infrastructure (no new files created).
This plugin provides a polling typology among the XTrigger Plugin.

Known limitations

Impossible to combine it with EnvInject plugin

Script Trigger plugin enables you to run an external script for knowing if job has to be scheduled, whereas EnvInject enables you to control environment variables when the job runs. Therefore, scripttrigger and EnvInject have 2 disctinct objectives. In conclusion, it is not possible to exploit envinject configuration. Your Script has to be standalone and independent from the job. Export your environment variables directly from your script.

Configuration

Changeling

Release 0.34

* Fix JENKINS-33328 - Cannot run trigger script on a slave node

Release 0.33

* Fix JENKINS-31017 - Description doesn't get the resolved variable

Release 0.32

* Add a MIT Lisence for all sources

Release 0.31

* Fix JENKINS-19379 - The scripttrigger plugins fails to load the parameter files when the System script is in use.

Release 0.30

* Fix JENKINS-18667 - NullPointerException when saving job config

Release 0.29

* Adding envvar replacement for groovyFilePath

Release 0.28

* Fix JENKINS-17641 \ Unknown field 'logEnabled' in org.jenkinsci.lib.xtrigger.XTriggerCause

Release 0.27

* Fix reopened JENKINS-17566 - Severe polling error when using script trigger

Release 0.26

* Fix JENKINS-17566 - Severe polling error when using script trigger

Release 0.25

* Test if the node is active when the polling do the work

Release 0.24

* Updat to xtrigger-lib 0.20
** Refactor error management

Release 0.23

* Fix polling issue by updating to org.jenkins-ci.lib:xtrigger-lib:jar:0.19:compile
- org.jenkins-ci.lib:envinject-lib:jar:1.16:compile

Release 0.22

* Re-adding newLine to line read in script content

Release 0.21

* Fix JENKINS-14535 - Fails to poll when no executors on master

Release 0.20

* Fix JENKINS-14104 - Use same node which has been specified in the "Restrict where this project can be run" field

Release 0.19

* Try to delete generated temporary file
* Upgrade to xtrigger-lib 0.12

Release 0.18

* Add an option to have concurrent builds
* Update to xtrigger-lib 0.11

Release 0.17

* Fix JENKINS-13542 - Backslashes in Environment / Script-Variables are not quoted correctly for Groovy
* Update to xtrigger-lib 0.10

Release 0.16

* Fix JENKINS-13208 - Use EnvVarsResolver for Groovy scripts
* Fix JENKINS-13209 -Support System Groovy scripts
* Merge pull request

  • Add system script checkbox in configuration UI
  • Add log/out/job variables to groovy shell
  • Setup the SYSTEM user during script execution
  • Log envvars used for script re-writing
  • Log messages and stack traces if the groovy script fails

Release 0.15

* Update to xtrigger-lib 0.8

Release 0.14

* Update to xtrigger-lib 0.7

Release 0.13

* Fixed JENKINS-11907 - scripttrigger doesn't close file

Release 0.12

* Environment variables are taken into account

Release 0.11.1

* Removed duplicate script resolution

Release 0.11

* Added cause and description attachment if they are present in the script execution output

Release 0.10

* Added the ability to inject environment variables with the EnvInject Plugin.

Release 0.9

* Added environment and job variables resolution to the script content

Release 0.8

* Fixed JENKINS-11042 - IOException when running ScriptTrigger with slaves
* Built for 1.409 (LTS series compatibility)
* Fixed log polling file

Release 0.7

* Fixed script execution node
* Refactoring

Release 0.6

* Added Jenkins environment variables resolution in script execution

Release 0.5

* Added the ability to provide scripts with a file path

Release 0.4.1

* Fixed a hep plugin message

Release 0.4

* Added a polling an the exit code of a shell script or a Windows batch script.

Release 0.3

* Improved help files
* Added a check: executing the script only if the Jenkins instance is not isQuietingDown() and the job is buildable

Release 0.2

* Added the feature: 'Can specify job properties as a properties file'

Release 0.1

* Initial release

25 Comments

  1. Some comments on this trigger:

    1°) the cron is still running even if the job is disabled. 

    Is there a way to avoid this?

    2°) The env variables are not available during the script execution

    1. For 1): Strange behavior. I can't reproduce it. Are you sure?
      We can follow the issue in JENKINS-1622
      For 2): Do you want environment system variables?

  2. I'd like to have the environment variables for the job (JOB_NAME, WORKSPACE, etc) available to the script.

  3. Thanks Gregory for the implementation of the last features

    - setting cause <cause></cause>

    - setting description <description></description>

    hoping that i'll not the only one to use them ;-)

  4. I'm trying to use EnvInject to pass some params to the script trigger but I cannot see the variables when the script executes. I can see the variables if I execute a build step.

    What am I doing wrong?

    1. Could you raise a bug report and provide your plugins version, jenkins version and upload your job configuration file (config.xml)?

  5. Is there a way to allow the script to inject ENV variables into the build?

    1. Yes there is a good way.
      Environment variables injection can be controlled with the EnvInject Jenkins plugin.

      ScriptTrigger is aimed at detecting changes in your infrastructure through your job configuration. With the above Envinject plugin, ScriptTrigger will inject environment variables used got by the last job build.

      1. I have this same need.   Can you add some detail on how this would work?

        Say for example, the Groovy trigger wants to set some env vars when triggering a run, which can be read later in the run block.    How would one tell the EnvInject plugin about these env vars?
        Is the idea to write those env vars to a file, then tell the EnvInject plugin to read from that file, or is there a better way?

  6. I gotta say, this trigger is pretty slick! We are now using it on our production Jenkins, and we love it.  Good job!

  7. I just upgraded from 0.13 to 0.17. I use shell script trigger to trigger concurrent builds throttling at 10 builds at a time. After the upgrade, the plugin does not trigger as expected and according to the crontab specified (every 2 min.). Instead it waits for the running build to finish and then triggers again. Which not what I want. I want it to disregard how many builds are running and to owner the crontab and the script exit code.

    What am I doing wrong?

    The log output from the plugin is:  'The job is building. Waiting for next poll'

    I'm gonna have to downgrade the plugin version until I figure out how to go over this problem.

    1. Yes, I added an option to avoid having multiple builds scheduled by trigger. It has to be the default behavior.
      I understand your use case.
      I added an option to enable concurrent builds.
      Please try version 0.18.

  8. Hi,

    For me, each scheduled poll with a Bash script leaves a file in /tmp (e.g. hudson3266510942082385978.sh) which is never deleted.

    I am running a job configured as below with

    • Script-trigger plugin v0.18
    • Jenkins v1.466
    • Ubuntu 10.04.

       -Andreas

    <?xml version='1.0' encoding='UTF-8'?>
    <project>
      <actions/>
      <description></description>
      <keepDependencies>false</keepDependencies>
      <properties/>
      <scm/>
      <canRoam>true</canRoam>
      <disabled>false</disabled>
      <blockBuildWhenDownstreamBuilding>false</blockBuildWhenDownstreamBuilding>
      <blockBuildWhenUpstreamBuilding>false</blockBuildWhenUpstreamBuilding>
      <triggers>
        <org.jenkinsci.plugins.scripttrigger.ScriptTrigger>
          <spec>*/1 * * * *</spec>
          <enableConcurrentBuild>false</enableConcurrentBuild>
          <script>true</script>
        </org.jenkinsci.plugins.scripttrigger.ScriptTrigger>
      </triggers>
      <concurrentBuild>false</concurrentBuild>
      <builders/>
      <publishers/>
      <buildWrappers/>
    </project>
    
    1. Please try version 0.19 and let me know.

      1. Hi Gregory,

        0.19 seem to do the trick! Great job!

           -Andreas

  9. Hello All,

     Do you know how you can tie the ScriptTrigger to a specific node (sometimes is using the master even if you have declared "Restrict where this project can be run" option)?

       For instance:

       Restrict where this project can be run: Label Expression: UBUNTU

       [ScriptTrigger] - Poll with a shell or batch script

    Polling started on 14-Jun-2012 07:00:59
    Polling for the job XXX_2.5
    Looking nodes where the poll can be run.
    Looking for a candidate node to run the poll.
    Looking for a polling node with the assigned project label ubuntu.
    Trying to poll on master node.
    
    Polling on master.
    The expected script execution code is 0
    Evaluating the script:
    

      Labels [master] : master

    Thanks

  10. Is there any way to use job's parameters during shell script polling?

    Also tried to use EnvInject plugin to set some variable in "Prepare an environment for the run", but just couldn't use this variable in polling script.

    In "Prepare an evironment..." at "Script content" I have:

    export QWERT='rrrrrr'

    At "Property content":

    QWER=/tmp

    And my polling shell script is:

    echo $QWERT
    echo $QWER
    exit 1

    But it don't see those variables:

    Evaluating the script:
    echo $QWERT
    echo $QWER
    exit 1
    [jenkins] $ /bin/bash -xe /tmp/hudson6965229684462568816.sh
    + echo
    
    + echo
    
    + exit 1
    
    1. Script Trigger plugin enables you to run an external script for knowing if job has to be scheduled, whereas EnvInject enables you to control environment variables when the job runs. Therefore, it is not possible to exploit envinject configurations. In conclusion, scripttrigger and EnvInject have 2 disctinct objectives. Your Script has to be standalone and independent from the job. Export your environment variables directly from your scripts.

  11. This is a fantasic plugin Gregory!

    Several of my jobs use variations of the same Groovy-script, so I am building up a library of functions I would like to re-use.

    Can anyone suggest how I might be able to explicitly configure a job-specific or global 'classpath' for ScriptTrigger so I can more easily import these common classes/functions from a file location without having to play around with system environment vars nor resorting to groovy evaluate hacks?

    At the moment, the classpath dumped in the GroovyScriptTrigger log is CLASSPATH=.

    1. Thanks David for your comment.
      If I understand your issue, you'd like to resume common objects in the ScriptTrigger plugin configuration through several jobs.
      Please look at the SharedObjects Plugin, maybe it could help you.

      1. Hi Greg,

        I tried this out today, but am so far unsuccessful. I can't find any examples of using the SharedObject plugin with ScriptTrigger Groovy scripts. Maybe you can assist?

        1. In Manage Jenkins -> Shared Objects :- I created & saved a "Simple content" SharedObject called "SharedObject_FTPClientUtils" with a value which is the groovy script source code. In my case, this comprises some groovy helper classes and functions for using apache commons FTPClient.

        2. In the Job -> Configuration -> [Script Trigger] - Poll with a Groovy script -> Groovy Script Content :-  I enter:

        import java.io.\*
        import org.apache.commons.net.ftp.\*
        ${SharedObject_FTPClientUtils}

        3. Checking the result in the Job's -> GroovyScriptTrigger Log :- The "Resolved Script" area does not list this Shared Object variable as a script variable, and does not resolve it, which suggests that it is not EnvVarsResolver compliant? However it does work resolving simple environment variables like: ${COMPUTERNAME} or ${GROOVY_HOME}.

        Let me know if I'm doing something wrong.

  12. I think I now understand more about how this plugin works. When scripttrigger runs a groovy script it is using the Jenkins built-in groovy (as per system console). As at current (2-Sep-2013) Jenkins 1.5.29 this is currently a quite old groovy 1.8.x.

    One advantage of this is that Groovy scripts (including environment injection) can be tested using the system console, but it also means that any external jars/resources must be added to WEB-INF/lib to be accessible by these scripts (by fluke I had installed the Publish-to-FTP plugin which provided commons.net.ftp classes for use by my script), the classpath is not maintainable.

    It'd be nice if ScriptTrigger were more like Groovy plugin, so that the runtime environment can be fully configured. I guess in the meantime, a work-around might be possible using ScriptTrigger's 'Batch script' functionality to execute Groovy CLI. Or I guess I might just have to bite the bullet and look into writing some kind of FTP Trigger Plugin myself for this use-case! :)