Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-53646

Agent command isn't in sync with remoting agent options

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: amazon-ecs-plugin
    • Labels:
      None
    • Environment:
      OS: ECS-optimized AMI 2018.03.f
      Jenkins : v2.138.1
      ECS plugin v1.16
    • Similar Issues:

      Description

      Current versions of Jenkins remoting (3.x) do not appear to support the -url and -tunnel options any more and instead favor using the -jnlpUrl option with the tunnel being added to the JNLPLauncher.

       

      Suggest updating the command being used in the ECS Task to be more in line with current versions of Jenkins:

      -jnlpUrl <jenkinsUrl>/computer/<agentName>/slave-agent.jnlp -secret <agentSecret> -workDir <agentWorkdir>

       

      instead of:

      -url <jenkinsUrl> -tunnel <tunnel> <agentSecret> <agentName>

        Attachments

          Activity

          Hide
          jtbouse Jeremy Bouse added a comment -

          So I did some digging into this and looking at the differences I mentioned.

          It appears that there is a distinct difference between how the Jenkins -> Node ->  <agentName> UI page shows to launch the agent and how the ECS Plugin and Docker image entrypoint are launching the agent.

          The Jenkins UI shows you to basically call it via:

          java -jar /usr/share/jenkins/slave.jar -jnlpUrl <jenkinsUrl>/computer/<agentName>/slave-agent.jnlp -secret <agentSecret>

          Which as I've deduced is calling using the hudson.remoting.launcher class using the jnlpUrl to pull down the encrypted JNLP file which it then decrypts using the secret and executes the hudson.remoting.jnlp.Main class with the arguments specified in the JNLP file.

          Whereas the ECS plugin and the typical Docker image entrypoint script launches the agent using a call like:

          java -Dorg.jenkinsci.remoting.engine.JnlpProtocol3.disabled=true -cp /usr/share/jenkins/slave.jar hudson.remoting.jnlp.Main -headless -url <jenkinsUrl> -tunnel <tunnel> <agentSecret> <agentName>

          Which directly calls the hudson.remoting.jnlp.Main class and passes the arguments directly requiring it to have intrinsic knowledge of the arguments needed.

          The hudson.remoting.launcher already appears that it executes with -headless already enabled and seems that calling the JNLP URL would be much more future proof.

          Obviously if the array built by the com.cloudbees.jenkins.plugins.amazonecs.ECSCloud.getDockerRunCommand() is changed this would require a change to how the entrypoint script handles it. So does it make more sense to do so?

          Show
          jtbouse Jeremy Bouse added a comment - So I did some digging into this and looking at the differences I mentioned. It appears that there is a distinct difference between how the Jenkins -> Node ->  <agentName> UI page shows to launch the agent and how the ECS Plugin and Docker image entrypoint are launching the agent. The Jenkins UI shows you to basically call it via: java -jar /usr/share/jenkins/slave.jar -jnlpUrl <jenkinsUrl>/computer/<agentName>/slave-agent.jnlp -secret <agentSecret> Which as I've deduced is calling using the hudson.remoting.launcher class using the jnlpUrl to pull down the encrypted JNLP file which it then decrypts using the secret and executes the hudson.remoting.jnlp.Main class with the arguments specified in the JNLP file. Whereas the ECS plugin and the typical Docker image entrypoint script launches the agent using a call like: java -Dorg.jenkinsci.remoting.engine.JnlpProtocol3.disabled=true -cp /usr/share/jenkins/slave.jar hudson.remoting.jnlp.Main -headless -url <jenkinsUrl> -tunnel <tunnel> <agentSecret> <agentName> Which directly calls the hudson.remoting.jnlp.Main class and passes the arguments directly requiring it to have intrinsic knowledge of the arguments needed. The hudson.remoting.launcher already appears that it executes with -headless already enabled and seems that calling the JNLP URL would be much more future proof. Obviously if the array built by the com.cloudbees.jenkins.plugins.amazonecs.ECSCloud.getDockerRunCommand() is changed this would require a change to how the entrypoint script handles it. So does it make more sense to do so?

            People

            Assignee:
            pgarbe Philipp Garbe
            Reporter:
            jtbouse Jeremy Bouse
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Dates

              Created:
              Updated: