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

2 views
Skip to first unread message

jglick@cloudbees.com (JIRA)

unread,
Jun 8, 2018, 9:42:02 AM6/8/18
to jenkinsc...@googlegroups.com
Jesse Glick created an issue
 
Jenkins / Improvement JENKINS-51811
KubernetesSlave should override getWorkspaceFor(TopLevelItem)
Issue Type: Improvement Improvement
Assignee: Carlos Sanchez
Components: kubernetes-plugin
Created: 2018-06-08 13:41
Priority: Major Major
Reporter: Jesse Glick

Olivier Lamy 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.

Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

jenkins-ci@carlossanchez.eu (JIRA)

unread,
Jun 8, 2018, 9:49:02 AM6/8/18
to jenkinsc...@googlegroups.com

jglick@cloudbees.com (JIRA)

unread,
Jun 8, 2018, 9:20:03 PM6/8/18
to jenkinsc...@googlegroups.com

jenkins-ci@carlossanchez.eu (JIRA)

unread,
Jun 12, 2018, 2:29:01 PM6/12/18
to jenkinsc...@googlegroups.com

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@cloudbees.com (JIRA)

unread,
Jun 12, 2018, 3:40:03 PM6/12/18
to jenkinsc...@googlegroups.com

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.

jenkins-ci@carlossanchez.eu (JIRA)

unread,
Jun 13, 2018, 2:47:02 AM6/13/18
to jenkinsc...@googlegroups.com

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@cloudbees.com (JIRA)

unread,
Jun 15, 2018, 5:18:02 PM6/15/18
to jenkinsc...@googlegroups.com

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@cloudbees.com (JIRA)

unread,
Sep 21, 2018, 5:50:04 PM9/21/18
to jenkinsc...@googlegroups.com

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

This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

jglick@cloudbees.com (JIRA)

unread,
Jul 16, 2019, 3:43:27 PM7/16/19
to jenkinsc...@googlegroups.com
Jesse Glick assigned an issue to Unassigned
Change By: Jesse Glick
Assignee: Carlos Sanchez
Reply all
Reply to author
Forward
0 new messages