Child pages
  • Parameterized Remote Trigger Plugin
Skip to end of metadata
Go to start of metadata

Plugin Information

View Parameterized Remote Trigger on the plugin site for more information.

A plugin for Jenkins CI that gives you the ability to trigger parameterized builds on a remote Jenkins server as part of your build.

Similar to the Parameterized Trigger Plugin, but for remote servers.

This is done by calling the /buildWithParameters URL on the remote server. (or the /build URL, if you don't specify any parameters)

This plugin also has support for build authorization tokens (as defined here ), and plays nicely with these other guys:

Screenshots

System configuration option


System configuration (via script)




import jenkins.model.Jenkins
import org.jenkinsci.plugins.ParameterizedRemoteTrigger.RemoteBuildConfiguration
import org.jenkinsci.plugins.ParameterizedRemoteTrigger.RemoteJenkinsServer
import org.jenkinsci.plugins.ParameterizedRemoteTrigger.auth2.CredentialsAuth;

// get Jenkins instance
Jenkins jenkins = Jenkins.getInstance();

def auth = new CredentialsAuth();
auth.setCredentials("credential.id")

def remoteJenkinsServer = new RemoteJenkinsServer();
remoteJenkinsServer.setDisplayName("instance.name");
remoteJenkinsServer.setAddress("instance.url");
remoteJenkinsServer.setAuth2(auth);
def descriptor = jenkins.getDescriptorByType(RemoteBuildConfiguration.DescriptorImpl.class);
descriptor.setRemoteSites(remoteJenkinsServer);

jenkins.save()




Job setup options

Change-log 

 

3.0.6 (Sep 19th, 2018)

New feature

  • Disable remote trigger job step instead of removing it

Improvement

  • None

Bug fixes

3.0.5 (Aug 20th, 2018)

New feature

  • None

Improvement

  • None

Bug fixes

3.0.4 (Jul 30th, 2018)

New feature

  • Support to abort remote job

Improvement

  • None

Bug fixes

3.0.3 (Jul 23th, 2018)

New feature

  • None

Improvement

  • Add concurrent connection restriction to prevent remote servers from blocking
  • Add job info. & crumb cache to reduce the dummy inquiries when parallel triggering

Bug fixes


Important change

  • jdk version must be at least v1.8

3.0.2 (Jul 18th, 2018)

New feature

  • None

Improvement

  • HTTP utility reorganized
    • post with form-data

Bug fixes

  • Fix parameters are too long (HTTP status 414)

3.0.1 (Jul 10th, 2018)

New feature

  • Support triggering remote jobs via Jenkins proxy

Improvement

  • code refinement

Bug fixes

  • [JENKINS-47919 ]( JENKINS-47919 - Getting issue details... STATUS ) (clarified & fixed)

3.0.0 (May 17th, 2018)

New feature

  • Pipeline support

     Improvement

     Bug fixes

2.2.0 (May 12th, 2015)

New Features/Enhancements:

  • Ability to debug connection errors with (optional) enhanced console output (pull request)

Bug fixes:

2.1.3 (July 6th, 2014)

A release release! Version 2.1.2 never made it to the plugin store due to a bug in the "maven release plugin" when using git 1.8.5.
Naturally, all changes from 2.1.2 are part of this release as well.

Bug fixes:

2.1.2 (April 26th, 2014)

Bug fixes:

2.1 (Feb 17th, 2014)

New Features/Enhancements:

  • ability to specify the list of remote parameters from a file (request ticket)
  • optionally block the local build until remote build is complete (request ticket)

Misc:
The console output has also been cleansed of displaying any URLs, since this could pose a security risk for public CI environments.
Special thanks to @tombrown5 for his contributions to the last item mentioned above

2.0 (Dec 25th, 2013)

New Features/Enhancements:

Misc:
Special thanks to @elksson for his contributions to the last 2 items mentioned above.

1.1 (Nov 30th, 2013)

Bug fixes:

  • closing potential security gap for public-read environments

New Features/Enhancemenst:

  • ability to not mark the build as failed if the remote build fails

Misc:

  • General code clean-up

1.0 

Initial release

Available features:

  • Trigger parameterized build on a remote Jenkins server
  • Trigger non-parameterized build on a remote Jenkins server
  • Authentication via username + API token
  • Support for "build token root" plugin

Issues

type key summary

Data cannot be retrieved due to an unexpected error.

View these issues in Jira

40 Comments

  1. It seems the latest (real) version (2.1.2) is not available from the Plugin Manager in Jenkins (core 1.563)

    I also got the latest version of the Credential, and Token Macro plugin (1.10 both)

    This is an issue, because I'm encountering this https://issues.jenkins-ci.org/browse/JENKINS-22325

    and cannot use this plugin properly :/

    1. Hi Lionel, did you get an answer to this? I too need the updated version but it still shows 2.1 as the latest version.

    2. Hey Lionel,

      There seems to have been a bug with the maven plugin that is used to release Jenkins plugins... which kept doing a snapshot release in place of an actual release. Because of that, 2.1.2 never actually made it to the update center.

      I found a way around the issue and confirmed that the newest version (2.1.3) is in the Update Center. So please try updating the plugin and let me know if the issue is still present.

  2. It seems the plug-in only support trigger a remote job as one step as part of the build.

    Would it possible to also add it in "Post-build Actions" ?  We need trigger the job from remote jenkins no matter it is success or failed. I see this might be useful since the parameter passing to the remote job could decide what to do next,

    Also, $PROJECT_NAME is not resolved passing as a parameter(it was received as string "$PROJECT_NAME" instead of the really project name ). $BUILD_NUMBER works fine.

    1. I second the request about being able to use this plugin as a Post-Build Step, this functionality is available in the "Parameterized Trigger Plugin"

  3. Is there any chance to get the latest version of this plugin published?  I'm hitting a blocking issue that appears to have been fixed but not published:

    https://issues.jenkins-ci.org/browse/JENKINS-26127

  4. Hi everyone,

    I had the same problem. Finally, I built the hpi extension starting from sources (git@github.com:jenkinsci/parameterized-remote-trigger-plugin.git) with "mvn install -DskipTests=true" (-DskipTests=true is required because some tests fail to execute, considering that it's a SNAPSHOT version) and I installed the plugin with my automation tools (it could be done also by hand, obviously).

    My installed version is 2.2.1-SNAPSHOT. As you know, it solves the java.net.MalformedURLException: no protocol: http%3A%2F%2Fmyserver exception. However, also the 2.2.0 (here is the link for the download https://github.com/jenkinsci/parameterized-remote-trigger-plugin/releases) solves the exception problem.

    I hope this will help you! :-)

    Luca

  5. Hi There,

    I am experiencing an authentication issue when attempting to resolve to Second Jenkins server behind a reverse proxy.
    It appears that the pluggin only operates on the direct jenkins url?

    Scenario: (Keeping https out of the discussion for simplicity)

    Jenkins Master A:  http://masterA.internal.com/jenkins
    Jenkins Master B:  http://masterB.azure.com/jenkins

    Above  Jenkins Masters have no ability to directly talk to each other. They can only access each other via the public websites which would look something like this:
    Master A: http://company.utils.com/jenkins
    Master B: http://company.azure.com/jenkins

    Working on Master A, I would like to call a job on Master B. A simple task if both Jenkins Master resided on the same network with no reverse proxy in the middle.

    I can only provide the public web address for Master B when I setup the remote trigger configuration in Jenkins A.

    When performing the "Validate Address" I will consistently get the following error: "Address looks good, but we were not able to connect to it"
    I have tried using both Username + API Token as well as "Use the Credentials Plugin"

    Any suggestions?

    ps: We have used this pluggin on many occasions for our other internal Jenkins Servers (all reside on the same network with no reverse proxy in the middle and https enabled)

    Any assistance will be much appreciated 

    Bruce

  6. I am getting issue with "Enable Enhanced Logging" functionality. 

    Initially, remote Jenkins server was using HTTP. In that case, plugin was able to get the console output of remote job successfully. 

    Now, remote Jenkins servers is SSL enabled (using HTTPS). After this change, plugin is not able to fetch the console output correctly.

    Did anyone face similar issue?

  7. I am facing one problem, For the Remote jobs inside the folder.
    Remote Jenkins server returned empty response or invalid JSON - but we can still proceed with the remote build.
    ERROR: Build step failed with exception
    java.lang.NullPointerException
    at org.jenkinsci.plugins.ParameterizedRemoteTrigger.RemoteBuildConfiguration.isRemoteJobParameterized(RemoteBuildConfiguration.java:1167)
    at org.jenkinsci.plugins.ParameterizedRemoteTrigger.RemoteBuildConfiguration.perform(RemoteBuildConfiguration.java:488)
    at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
    at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:782)
    at hudson.model.Build$BuildExecution.build(Build.java:205)
    at hudson.model.Build$BuildExecution.doRun(Build.java:162)
    at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:534)
    at hudson.model.Run.execute(Run.java:1738)
    at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
    at hudson.model.ResourceController.execute(ResourceController.java:98)
    at hudson.model.Executor.run(Executor.java:410)
    Build step 'Trigger a remote parameterized job' marked build as failure
    Notifying upstream projects of job completion
    Finished: FAILURE

    What could be causing this?
    Any help is appreciated. Thanks!

  8. I am using the this plugins.

    But I have one problem.

    If the other Jenkins server is not reachable, the option

    "do not fail if Remote fails" is useless.

    it fails with an exception (see below).

    I authentificate with

    user + API

      &

    jobname+job-token

    is there an possibility to avoid or extend the plugin so unreachable servers do not fail the job too?

    ----mee_my_wrong_Remote_Jenkins
    Connection to remote server failed, waiting for to retry - 10 seconds until next attempt.

    Retry attempt #1 out of 5
    mee_my_wrong_Remote_Jenkins
    Connection to remote server failed, waiting for to retry - 10 seconds until next attempt.

    Retry attempt #2 out of 5
    mee_my_wrong_Remote_Jenkins
    Connection to remote server failed, waiting for to retry - 10 seconds until next attempt.

    Retry attempt #3 out of 5
    mee_my_wrong_Remote_Jenkins
    Connection to remote server failed, waiting for to retry - 10 seconds until next attempt.

    Retry attempt #4 out of 5
    mee_my_wrong_Remote_Jenkins
    Connection to remote server failed, waiting for to retry - 10 seconds until next attempt.

    Retry attempt #5 out of 5
    mee_my_wrong_Remote_Jenkins
    ERROR: Remote build failed for the following reason, but the build will continue:
    ERROR: Max number of connection retries have been exeeded.
    ERROR: Build step failed with exception
    java.lang.NullPointerException
    at org.jenkinsci.plugins.ParameterizedRemoteTrigger.RemoteBuildConfiguration.isRemoteJobParameterized(RemoteBuildConfiguration.java:1167)
    at org.jenkinsci.plugins.ParameterizedRemoteTrigger.RemoteBuildConfiguration.perform(RemoteBuildConfiguration.java:488)
    at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
    at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:785)
    at hudson.model.Build$BuildExecution.build(Build.java:205)
    at hudson.model.Build$BuildExecution.doRun(Build.java:162)
    at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:537)
    at hudson.model.Run.execute(Run.java:1741)
    at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
    at hudson.model.ResourceController.execute(ResourceController.java:98)
    at hudson.model.Executor.run(Executor.java:408)
    Build step 'Trigger a remote parameterized job' marked build as failure
    Collecting metadata...
    Metadata collection done.

    Finished: FAILURE

  9. Hello.  

    Am using this plugin version 2.13, it was just installed by the Jenkins admin person, I am not sure why the latest 2.2.0 was not installed, unless this plugin needs a newer Jenkins, our Jenkins is quite old (1.565.3).  But an plugin update from 2.1.3 to 2.2.0 is not showing up on our "Plugin Updates" page, so as far as our Jenkins is concerned it appears to be the latest version.

    The documentation does not explain the various authentication credentials - are any actually required if "None" is an allowed type ?  I am trying to use this Plugin, without specifying a authentication type.   get  the following error:

    Triggering this remote job: test_vottbld330
    Not checking if the remote job test_vottbld330 is building.
    This job is build #[5] on the remote server.
    Triggering remote job now.
    Connection to remote server failed, waiting for to retry - 10 seconds until next attempt.
    Retry attempt #1 out of 5
    

    It appears as if the remote server has been contacted by looking at the the results of the third line above, since the local job knows the remote build number will be #5, which is indeed the number of next build of the remote job.So, if the remote server has been contacted as of line 3, then why does it fail as of line 5? The first and third authentication types presented during configuration of the plugin seems obvious (None, and "Use the credentials Plugin", but what is the second type of authentication "Userid + API token" ? How is this supposed to be used?

  10. This plugin appears to not work as advertised.

    Parameters from file does not work at all.

    variable expansion only works for pre-defined variables, not for variables present in the job.

  11. I provide a reasonable bash script for performing the same action as this - currently broken - plug-in

     #!/usr/bin/env bash
    
    # Makes up for a failed Jenkins plugin
    
    set -x
    
    URL=""
    PARAMS=""
    
    function usage () {
    
       echo "$0 URL [name1=val1] [name2=val2] ..."
       echo "NOTE:  As with all BASH parameters, enclose spaces with quotes"
    }
    
    function build_params_json () {
    
       URL=$1
       shift;
       # Build up a json parameter string that looks like this
       #        '{"parameter": [{"name":"NAME", "value":"VALUE"}, {"name":"BLAH", "value":"FOO"}]}'
       PARAMS='{"parameter": ['
       while [ "$1" != "" ]; do
          # Rely upon BASH's awesome text manipulation built-ins
          NAME="${1%=*}"
          VALUE="${1#*=}"
          PARAM="{\"name\":\"$NAME\", \"value\":\"$VALUE\"}"
          shift;
          if [ ! -z "$1" ]
          then
             PARAM="$PARAM,"
          fi
          PARAMS="$PARAMS $PARAM"
       done
       PARAMS="$PARAMS]}"
    }
    
    function trigger () {
       curl -X POST "${URL}" --data token=TOKEN --data-urlencode json="${PARAMS}"
    }
    
    function main () {
    
       # parameter #1 is the full url to the parameterised job
       # remaining params are "name=value" pairs
       if [ -z $1 ]
       then
          usage
       fi
       build_params_json "$@"
       trigger
    
    }
    
    main "$@"
    
  12. While simple, this plugin could be pretty useful. I've tested some of the pull requests out there already and would be interested in extending this. Does this plugin need a new maintainer?

    1. I think it does, maybe grab it? I could do with some love.

    2. how can a new maintainer be assigned? Does the existing maintainer have to approve someone?

  13. This plug-in doesn't seem like it's maintained anymore, so we created a simple workaround script that provides the same functionality and more, allowing real-time console output. 

    https://github.com/optimizely/remote-jenkins-job

     

  14. I also write a simple script to do the similar functions, 

    https://github.com/cashlalala/py_jenkins_job_trigger

  15.  

    On the Parameters Field we cold have something like a IF conditions ?

    if [ ${DESTINATION_BRANCH} == "release" ] 

    then

        Pparameter1 = "test-release"

    fi

     

    At this moment look is working only to have directly assinged the value:  Pparameter1 = "test-release"

     

    Without a IF condition.

  16. If there is a provision to abort the job remotely when I abort it on client side, that will be a great feature. Right now, if I start a job remotely and abort in between, it will still continue on remote host and it might creates duplicate jobs when I run it again.

    1. It's a reasonable request, I'll find some time to implement it whose major effort would be massive parallel abortion.

      1. I'm not sure what you mean by "massive parallel abortion", however this would be a much useful feature for people who are executing remote jobs.

        1. It's okay, don't care about it.

          This function was already supported in v3.0.4, you may give it a try.

          1. Thank you, will try this and let you know !

          2. This is working like a charm, awesome !!

            Thank you for adding such a feature in this pace.

             

  17. To maintainers: A really useful (and I think should be easy) option to add would be a "Disable" checkbox. This way if a certain remote job was having problems and needed to be skipped for a little while you could just Disable it from the parent job instead of having to remove it from the parent job.

    What do you think? Thank you.

    Please reply to raye dot raskin at spigit dot com. Don't know why it's using https://wiki.jenkins.io/display/~ircbot.

    1. I know what you mean, I'll do it in next release

    2. released in v3.0.6, give it a try

      1. Thank you. Works nicely!

  18. If the remote server is offline, we get this in the logs:

    ################################################################################################################
    02:30:16 - 15 Sep fail to accquire lock because of timeout, skip locking...
    02:30:18 - 15 Sep Triggering parameterized remote job 'https://...'
    02:30:18 - 15 Sep   Using job-level defined 'Credentials Authentication' as user 'xxx.xxx' (Credentials ID '')
    02:30:18 - 15 Sep Triggering remote job now.
    02:30:28 - 15 Sep fail to accquire lock because of timeout, skip locking...
    02:30:28 - 15 Sep CSRF protection is disabled on the remote server.
    02:30:39 - 15 Sep fail to accquire lock because of timeout, skip locking...
    02:30:39 - 15 Sep The remote job is buildable. ‘remoteSlave’ is offline.
    02:30:39 - 15 Sep   Remote job queue number: 79
    02:30:39 - 15 Sep Waiting for remote build to be executed...
    02:30:39 - 15 Sep Waiting for 10 seconds until next poll.
    02:30:59 - 15 Sep fail to accquire lock because of timeout, skip locking...
    02:31:00 - 15 Sep The remote job is buildable. ‘remoteSlave’ is offline.
    02:31:00 - 15 Sep Waiting for 10 seconds until next poll.
    02:31:20 - 15 Sep fail to accquire lock because of timeout, skip locking...


    And unfortunately this just keeps going and going until we abort the job. Is it possible to have handling for when the slave is offline i.e. a maximum number of retries, and if it cannot get there, then it will act according to the 'Do not fail if remote fails' flag?

    1. yo, Stuart Smith which version did you use? 

      Let me try to reproduce it. 

      1. We are on version 3.0.5

    2. I had tried the same scenario which started building a remote job and closed the remote server , but it ended correctly which retried & stopped. 


      Maybe you can issue a Jira ticket and attach more remote trigger related log for tracking.

      BR

  19. Hi. We always get several of these messages, even when everything runs fine:

        fail to accquire lock because of timeout, skip locking...

    How can we eliminate these messages? The fewer false errors, the better.

    Thank you.

    1. The message is more like a debug message which I should only enable it in debug mode,

      I'll add an debug option in global setting for this kind of messages.

      If you're really suffering from this for now, suggest to increase the max connection like 5 or ten perhaps. 




  20. I have noticed that the plugin waits for some time (the poll interval) even before triggering the remote job. Is this expected?

    Here is an example. Assuming that the poll interval is set to 60 (1 minute) ,then the plugin would print the following and then wait for 60 seconds.

    ################################################################################################################
      Parameterized Remote Trigger Configuration:
        - job:                     REMOTE_JOB_NAME 
        - remoteJenkinsName:       REMOTE_JENKINS_SERVER
        - parameters:              [Param1=master, Param2=./tmp.RxNcOUHx6A]
        - blockBuildUntilComplete: true
        - connectionRetryLimit:    5
    ################################################################################################################

    Next, the following line is printed, and again sleep for 60 seconds

    fail to accquire lock because of timeout, skip locking...
    Triggering parameterized remote job 'http://jenkins.company.com/job/REMOTE_JOB_NAME'

    Next, the following line is printed, and again sleep for 60 seconds

    Triggering remote job now.
    fail to accquire lock because of timeout, skip locking...
    CSRF protection is enabled on the remote server.
    fail to accquire lock because of timeout, skip locking...
      Remote job queue number: 169710
    Remote build started!
      Remote build URL: http://jenkins.company.com/job/REMOTE_JOB_NAME/69/
      Remote build number: 69
    

    IMO, I believe this is a bug. The poll interval should only be used after the job is triggered (this means that the first 2 sleeps here should not be there). Reason why this is important is because some jobs take long time. In my case, the remote job takes 2 hours. I would like to use a poll delay of 10 mins but waiting for 20 mins before the job is triggered is inconvenient.


    Thank you in advance for considering our requrest.

    1. Yeah, it does take time to wait for a new build in remote Jenkins, but, appraently, not as long as what you configured in the setting.

      I'll check it and release in next version. 

      1. Hi KaiHsiang Chang, do you have an ETA when this will be released? Thanks in advance.