I assume that this ticket also covers the "Oops" when one navigates to a workspace on a slave that's currently off-line (e.g. http://localhost:8080/job/MyWorkflow/3/execution/node/3/ws/ )? A friendlier error message, with slave name etc, would be good. However, a direct link to the slave node would be better, and a REST api would be best.

Currently a 404 is served when the workspace is unavailable. I was not aware this renders using oops.jelly; if so, that is a mistake. Anyway the first item covers replacing this with noWorkspace.jelly.

If the flow graph UI isn't available in the OSS version there needs to be some other way to manage the workspace, e.g. delete it.

The flow graph is present in the workflow-job plugin. But deleting the workspace is not yet implemented, as already noted here (third item).

SCM.processWorkspaceBeforeDeletion should also be checked during

• DeleteDirStep (JENKINS-30346)
• WorkflowJob.performDelete

WorkspaceListener could also be fired if it were updated to grok Job.

WorkspaceCleanupThread also needs editing.

It looks like the Workflow plugin may actually be preventing all divs with the class "subtasks" from appearing, regardless of whether or not the Workflow plugin is actually in use on the job in question. For example, the "Wipe Out Current Workspace" option does not appear, which would normally be a child task div of the child subtasks div of the workspace task div. If using the Role-Based Access Control plugin, this issue also affects the "Filter" option which would normally appear under "Roles."

feuchtcc I am unaware of any such problem, but if true it would be a bug, quite distinct from this RFE. Since it sounds like you are a CloudBees customer you should open a support ticket with details.

jglick I found my way here from this ticket: https://issues.jenkins-ci.org/browse/JENKINS-28382

I do have an open support ticket with CloudBees, but I figured I'd come from all angles.

Another thing to do: show the @tmp variant of the workspace if it exists (no, could be a security risk).

Hi guys - any news on having this feature available for the Pipeline jobs ?

Also it may be useful to ease the access to a build/job workspaces. Having to navigate in pipeline steps to find workspaces isn't user friendly. Maybe we could:

1) have a workspace icon (and link) nearby the console icon where relevant on steps view.
2) have a "Workspaces" link on the pipeline job page that opens a "pop up layer" (just as logs does) listing all the workspace links used in the last pipeline build, just as the workspace link of a "standard job" shows the content of the workspace of the last job link.

check this out https://www.selikoff.net/2016/07/10/workspace-jenkins-pipelines/

Thanks guys for tracking this issue , please keep us informed
tarzain great , thanks for sharing us this tip

Not to forget a way to expose the workspace links within the pipeline.

This is useful for notifications (mail and the like) or may be used for links in the job description (to provide a convinient way of adressing parts of the build result).

For all those who're particular to look the workspace of multi branch pipeline jenkins projects, please navigate to the build run and click “pipeline steps”, then click “allocate node: start” ( for multiple nodes, this shall be done as required) Tadaaa..!!! you've your workspace button in the left

https://github.com/jenkinsci/external-workspace-manager-plugin actually supports browsing of workspaces for Pipeline, but it requires extra configuration

oleg_nenashev that is unrelated. This issue is just about exposing a proper UI for workspace access in Pipeline builds, without changing runtime behavior.

I understand. This is just one of possible workarounds if the feature is really needed

Filed PR with a basic display for classic UI. 2015-09-11 comments, as well as some miscellaneous fixes such as adding a wipe out workspace link, need to be refiled as separate issues, but I think this captures the most common and obvious request.

A way to easily view all of the workspaces for a specific build (the fourth bullet point in the description) was just added in version 2.24 of Pipeline Supporting APIs Plugin as a sidebar link named Workspaces on the build page.

Is there now a means to get the "workspace URL of multi branch pipeline jenkins projects" programmatically ? Such that I can:

• add it into an email
• expose it even within the job itself
  in the tests we are running I want to print an URL to the workspace for failing tests.

Yes, I can navigate by hand to the workspace via the pipeline steps, but that is very cumbersome with 8 (or more) parallel branches.
I've even added a  hard-code lookup table in my script, but that breaks as soon as I start multiple of the same jobs.

NB: when I hover the mouse over the "Allocate node : Start" message, I do get a popup with "ID: 71" or so. All I need is that ID number within my "node {}" block ..

someone please,,,

dnusbaum : would you have an idea ? Just needed to update my pipeliine scripts, and  again the ID's changed...

monger39 The fix to this ticket created a new page that lists all workspaces used by the build which is always accessible via a URL like <JENKINS_HOST>/jobs/<JOB_NAME>/<BUILD_NUMBER>/ws, which might be good enough for your purposes.

If you really need to construct a link to the current workspace inside of of a Pipeline, my recommendation would be to create a new step that looks through enclosing blocks for WorkspaceAction and uses that to return or print a link to the logs. Either way, it would be better to create a new RFE or discuss on the mailing list rather than commenting on this ticket.

dnusbaum : can you point me to an example to "create a new step that looks through enclosing blocks for WorkspaceAction and uses that to return or print a link to the logs" ? I would not have an idea how to get that.

For now I implemented a dirty workaround: I made a script that fetches (wget) the  .../lastBuild/flowGraphTable page, and extracts the lines have the info that I need.
This script I call from my job and generate a table of the numbers (the ID's) that I need. This is obviously far from perfect, but hopefully is sort of auto-correcting.

I still am hoping for a simple currentBuild.Info.something.ID solution ...