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

KubernetesSlave should override getWorkspaceFor(TopLevelItem)

    XMLWordPrintable

Details

    Description

      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.

      Attachments

        Issue Links

          Activity

            it could be the cause of JENKINS-51695

            csanchez Carlos Sanchez added a comment - it could be the cause of JENKINS-51695
            jglick Jesse Glick added a comment -

            Maybe, but I do not see any connection.

            jglick 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.

            csanchez 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.
            jglick 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.

            jglick 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

            csanchez 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
            jglick 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.

            jglick 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 .
            jglick Jesse Glick added a comment -

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

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

            People

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

              Dates

                Created:
                Updated: