Workspaces and slave nodes

[Robert Moore]

This behavior seems new to me but perhaps I've just overlooked it in the past. We are building slave nodes and after the nodes have gone offline are not able to access the workspace (we see "Error: no workspace" when trying to access it). Is this by design or a bug?

Thanks,

Rob

[Scott Evans]

I see the same behavior and certainly assume it is by design. The
workspaces are likely still there and can be accessed directly if
you're on that node itself, just not through Jenkins.

Scott

> --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Kevin Fleming (BLOOMBERG/ 731 LEXIN)]

Yes, this is how it is expected to work. Access to the workspace is performed through the open connection to the Jenkins slave on the node; the workspace is not copied to the Jenkins master. This causes problems in some areas; for example, the Warnings plugin does not copy referenced source files to the master, it assumes they will still be available in the workspace, which means if the node is not available, or the workspace has been cleaned out, or the files have been changed, the linked-to file is not available or doesn't match the warning.

[Moore, Robert]

OK, thanks for the explanation. In the case of using EC2 slaves that come and go quite frequently this seems to be problematic. I see there is a plugin that allows for copying from a slave to a master but even then it seems unlikely the workspace link would function correctly.

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-users/2Sfzzfz40T0/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to jenkinsci-use...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Robert Moore

Architect

PIF Data

K-12 Technology

400 Center Ridge Drive

Austin, TX 78753-1034

D: 512.989.5476 (Intra-Pearson: 22-5476)

M: 512.567.5192

Pearson

Always Learning

[Kevin Fleming (BLOOMBERG/ 731 LEXIN)]

This is my use case as well (slaves on EC2), and you are correct. I wouldn't want to copy the entire workspace to the master after every job (that would be quite time and disk space consuming), but not having it available later is annoying.

I've got items on my to-do list to investigate whether some of the plugins I use can be improved to not require the workspace to still be around, but this only addresses part of the issue.

D: 512.989.5476 (*Intra-Pearson: 22-5476*)

M: 512.567.5192

*

*

*Pearson*

Always Learning

[Sami Tikka]

I myself have rarely considered this a problem. The workspace would anyway be overwritten by the next build, so it is better not to trust it's existence or contents.

If I need to debug a problem with a job, I either:

* Disable the job to prevent next build from overwriting the workspace or
* Configure the job to archive necessary debug logs and later access them via build artifacts.

If you really need to preserve the full workspace for your builds, you can of course tell Jenkins to archive every file in the workspace as build artifact or use https://wiki.jenkins-ci.org/display/JENKINS/Clone+Workspace+SCM+Plugin. This will be slow and might use a lot of disk space.

-- Sami

[Moore, Robert]

The problem for us is that there are links to artifacts in Jenkins that are 'dead' because the content they are pointed to is removed after the server is shutdown. An example is code coverage information. I wouldn't mind if the content was overwritten with the latest data but having absolutely no data available unless the slave happens to be running is rather surprising for the user.

[Kevin Fleming (BLOOMBERG/ 731 LEXIN)]

Yes, this is exactly where I noticed it as well (using the Cobertura plugin).

Personally, I think a better way to solve the issue for this plugin (and the warnings plugin) would be for them to construct links back to the web-view of the SCM where the code came from, assuming the job's SCM provider makes such information available (the Git plugin does, for example). I started playing around with this a couple of months ago but didn't get anywhere quickly and then got pulled into other work. It should be fairly straightforward though, and would completely eliminate this problem.