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

KubernetesSlave should override getWorkspaceFor(TopLevelItem)

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • kubernetes-plugin
    • None

      olamy noticed some problems running tests in a multibranch project using K8S due to the tests using Unix sockets, which imposes a very low limit (PATH_MAX IIRC) on the length of the workspace directory name plus whatever subdirectory your stuff runs in. JENKINS-34564 means that the default branch project workspace path is fairly long in most cases, which caused problems for example with socket-based sshagent before JENKINS-36997 switched to a CLI implementation.

      At any rate, the entire reason for selecting a workspace path which is unique among all possible branch projects in the Jenkins instance—to avoid clashes between projects—is moot when using a K8S agent, since these are allocated dynamically within the scope of the build. So while the Slave.workspaceRoot is by default /home/jenkins/workspace, which is fine, the workspace for the build is /home/jenkins/workspace/project-PR-5-ABC123SOMETHINGVERYVERYLONG, which is pointless. Assuming the KubernetesSlave is normally used for a single build, it should just

      @Override
      public FilePath getWorkspaceFor(TopLevelItem item) {
          if (item.equals(howeverYouDetermineTheOwningBuild().getParent())) {
              return getWorkspaceRoot().child("main");
          } else {
              return super.getWorkspaceFor(item);
          }
      }
      

      so that the build will run inside /home/jenkins/workspace/main—a nice short, predictable name.

          [JENKINS-51811] KubernetesSlave should override getWorkspaceFor(TopLevelItem)

          it could be the cause of JENKINS-51695

          Carlos Sanchez added a comment - it could be the cause of JENKINS-51695

          Jesse Glick added a comment -

          Maybe, but I do not see any connection.

          Jesse Glick added a comment - Maybe, but I do not see any connection.

          I don't know a way to know what build does an agent belong to
          Don't follow what is item.equals(howeverYouDetermineTheOwningBuild().getParent()) trying to do.

          Carlos Sanchez added a comment - I don't know a way to know what build does an agent belong to Don't follow what is item.equals(howeverYouDetermineTheOwningBuild().getParent()) trying to do.

          Jesse Glick added a comment -

          I don't know a way to know what build does an agent belong to

          IIUC these agents are normally created by the podTemplate step, right? If so, you should have some record of which build ran that step. Maybe I misunderstand how the plugin works.

          Don't follow what is … trying to do.

          Ensuring that we are only modifying the selection of workspace for builds belonging to the job which actually launched this agent.

          Jesse Glick added a comment - I don't know a way to know what build does an agent belong to IIUC these agents are normally created by the podTemplate step, right? If so, you should have some record of which build ran that step. Maybe I misunderstand how the plugin works. Don't follow what is … trying to do. Ensuring that we are only modifying the selection of workspace for builds belonging to the job which actually launched this agent.

          IIUC these agents are normally created by the podTemplate step, right? If so, you should have some record of which build ran that step

          correct, but I don't know how to get a reference from KubernetesSlave to Run

          I can see Run reference in PodTemplateStepExecution, somehow this needs to be saved to the Slave? or the slave can access the context in any other way? any pointers ?

          https://github.com/jenkinsci/kubernetes-plugin/blob/4dca515597efd94af733af89ee56799d20db0652/src/main/java/org/csanchez/jenkins/plugins/kubernetes/pipeline/PodTemplateStepExecution.java#L63

          Carlos Sanchez added a comment - IIUC these agents are normally created by the podTemplate step, right? If so, you should have some record of which build ran that step correct, but I don't know how to get a reference from KubernetesSlave to Run I can see Run reference in PodTemplateStepExecution, somehow this needs to be saved to the Slave? or the slave can access the context in any other way? any pointers ? https://github.com/jenkinsci/kubernetes-plugin/blob/4dca515597efd94af733af89ee56799d20db0652/src/main/java/org/csanchez/jenkins/plugins/kubernetes/pipeline/PodTemplateStepExecution.java#L63

          Jesse Glick added a comment -

          somehow this needs to be saved to the Slave

          Sure, you could save the Run.getExternalizableId in some field in the KubernetesSlave. Or for purposes of this issue you just need the Job.getFullName so you can compare to that of the supplied TopLevelItem.

          Jesse Glick added a comment - somehow this needs to be saved to the Slave Sure, you could save the Run.getExternalizableId in some field in the KubernetesSlave . Or for purposes of this issue you just need the Job.getFullName so you can compare to that of the supplied TopLevelItem .

          Jesse Glick added a comment -

          For comparison the dockerNode step just sets the workspace to be a fixed subdirectory.

          Jesse Glick added a comment - For comparison the dockerNode step just sets the workspace to be a fixed subdirectory.

            Unassigned Unassigned
            jglick Jesse Glick
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: