Hi Antonio,
Thanks for confirming what I thought.
Of course I did think about deleteDir() inside a node{} call, but this is
undesirable because we know that workspaces will be shared between any
node{} elements, so I would be deleting the contents of a previous node{}
block, and not necessarily the workspace contents of the current node{}
block only.
I've made a logical association that a node{} block is like a classical
Jenkins Job (with it's allocated workspace). This now seems wrong. It seems
that actually the Pipeline makes the whole Jenkinsfile 1x logical job, and
the node{} blocks just allow different node selections during that job.
My problem here is that my Jenkinsfile defines 3x very different logical
jobs 1) Building code, 2) Packaging (rpm, deb, zip, etc), 3) Publishing the
packages to a HTTP API. It seems to me that at the moment with pipeline 1x
Git Repository = 1x Jenkinsfile = 1x Logical job (and shared workspaces
between node{} elements). Each of these 3x different jobs need clean
workspaces that are not shared (because the Packaging node{} block might
get a Publishing workspace.
- James
On Tuesday, 21 June 2016 12:19:08 UTC+1, Antonio Muñiz wrote:
>
> Right, the workspace will be reused for the same job in the while running
> in the same node.
>
> You can use `deleteDir()` step as the very first call on every node block.
> It will clean the workspace.
>
> On Thu, Jun 16, 2016 at 4:43 PM, James Read <xconsp...@gmail.com
> <javascript:>> wrote:
>
>> Hey folks,
>>
>> I went poking around in the Jenkins source, and it seems that
>> WorkspaceList.allocate() allows for workspace re-use if executor threads
>> share the same context. Given that I've got a single master with some
>> executors (small environment) and a single pipeline, I assume that my
>> executor context never changes (or changes rarely). I didn't find out if a
>> single executor is allocated to a pipeline, or node{} calls create
>> new/reuse executors.
>>
>> I see that in start() WorkspaceStepExecution.java, the call to
>> getWorkspaceList().allocate(baseWorkspace) seems like it would always allow
>> this reuse. Gonna go hunting around on the bug tracker to see if this is
>> just me or I'm doing something horribly wrong though :P
>>
>> - James
>>
>>
>> On Wednesday, 15 June 2016 15:54:32 UTC+2, James Read wrote:
>>>
>>> Hey folks,
>>>
>>> I'd like to understand how Jenkins Pipeline allocates workspaces - I'm
>>> alarmed that subsequent node {} elements in a Jenkinsfile appears to
>>> allocate the same workspace. It's causing problems with conflicting or
>>> missing files. My Jenkinsfile looks like this;
>>>
>>> stage "Testing"
>>>
>>> node {
>>> // This will allocate a "default" workspace.
>>> writeFile file: "workspace_1st_node_block.txt", text:
>>> "${pwd()}"
>>> }
>>>
>>> node {
>>> // I think this *should* create another workspace, but it
>>> doesn't, it reuses the 1st workspace.
>>> writeFile file: "workspace_2nd_node_block.txt", text:
>>> "${pwd()}"
>>> }
>>>
>>> node { ws {
>>> writeFile file: "workspace_subworkspace.txt", text:
>>> "${pwd()}"
>>> }}
>>>
>>>
>>> When the build of this Jenksinfile completes, if I do a `tail` on the
>>> contents of these workspaces from the Jenkins master, it looks like this;
>>>
>>> ==> workspace@2/workspace_subworkspace.txt <==
>>>
>>> /var/lib/jenkins/jobs/jamesread/jobs/testcase-jenkins-pipeline-workspaces-reuse/branches/master/workspace@2
>>>
>>>
>>> ==> workspace/workspace_1st_node_block.txt <==
>>>
>>> /var/lib/jenkins/jobs/jamesread/jobs/testcase-jenkins-pipeline-workspaces-reuse/branches/master/workspace
>>>
>>>
>>> ==> workspace/workspace_2nd_node_block.txt <==
>>>
>>> /var/lib/jenkins/jobs/jamesread/jobs/testcase-jenkins-pipeline-workspaces-reuse/branches/master/workspace
>>>
>>>
>>> I would have expected 3 workspaces to be created, but instead just 2
>>> were created (one by the 1st node{} declaration, one by the ws {}
>>> declaration). I've created this as a testcase in the following GitHub repo;
>>> https://github.com/jamesread/testcase-jenkins-pipeline-workspaces-reuse/
>>>
>>>
>>> In my real project, I've resorted to wrapping each step in a "node { ws
>>> {" to force new workspaces to be created, but now it seems that even these
>>> workspaces are being reused! Just to restate, my questions are;
>>>
>>> 1) Is workspace re-use expected, and I just have the wrong expectation?
>>>
>>> 2) An ideal situation would be that the worksapces are ephemeral, and
>>> are deleted when the job completes. But I could not find a reliable way to
>>> do this yet in a Jenkinsfile. Is this possible?
>>>
>>> Thanks.
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-use...@googlegroups.com <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-users/fb31cd9e-ec39-42c8-ab10-ebe94b820916%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/jenkinsci-users/fb31cd9e-ec39-42c8-ab10-ebe94b820916%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Antonio Muñiz
> Software Engineer
> CloudBees, Inc.
>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/89758eec-0b09-44e1-ade3-5206dedbaada%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
