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

Agent command isn't in sync with remoting agent options

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • amazon-ecs-plugin
    • None
    • OS: ECS-optimized AMI 2018.03.f
      Jenkins : v2.138.1
      ECS plugin v1.16

      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>

          [JENKINS-53646] Agent command isn't in sync with remoting agent options

          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?

          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?

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

              Created:
              Updated: