Details
-
Improvement
-
Status: Resolved (View Workflow)
-
Minor
-
Resolution: Fixed
-
None
-
-
Jenkins 2.214, workflow-durable-task-step 2.36
Description
WorkspaceList.createTempDir (JENKINS-27152) is used by various plugins, and from Pipeline builds you can even use pwd tmp: true to use this location for custom purposes, but this is awkward. In practice many scripts wind up just binding this to a variable (example). We should define it out of the box.
$WORKSPACE is used for the main workspace (though not frequently needed as this is also the default working directory). $WORKSPACE_TMP seems like an intuitive name for the new property and matches the style of the @tmp suffix. Standard practice in Linux is to allow $TMPDIR to define a temporary directory, but using this variable name would result in a behavioral change for some existing scripts that may be unwanted, for example if /tmp is a RAM filesystem while the Jenkins workspace is persistent; we would like to offer a facility that users can opt in to where it makes sense (for example for project-specific caches) but not where it does not make sense (temporary files that are soon after deleted).
Attachments
Issue Links
- causes
-
JENKINS-61197 Running a job with a custom workspace set to eg. 'F:\' causes NullPointerException
-
- Resolved
-
- relates to
-
-
- Resolved
-
- links to
Activity
Suppose, in a static agent scenario, that I want to bind TMPDIR to a place where users can indiscriminately write gigabytes of "stuff" that will get automatically cleaned up at the end of the build. Also suppose that all of my jobs have a cleanWs() step in a finally block before any ws or node block goes out of scope. Would you prefer #1 or #2:
- Use a withEnv block to bind TMPDIR to the result of e.g. mktemp -d -p "${WORKSPACE}".
- Use a withEnv block to bind TMPDIR to WORKSPACE_TMP and then patch cleanWs() to delete all suffix directories (including WORKSPACE_TMP) as some users have suggested in JENKINS-41805 (comment),
JENKINS-44909, and JENKINS-50797.
#1 seems simpler and safer to me, but I thought I'd check to see if you thought there were any arguments for #2.
Basil Crow
added a comment - - edited Suppose, in a static agent scenario, that I want to bind TMPDIR to a place where users can indiscriminately write gigabytes of "stuff" that will get automatically cleaned up at the end of the build. Also suppose that all of my jobs have a cleanWs() step in a finally block before any ws or node block goes out of scope. Would you prefer #1 or #2:
Use a withEnv block to bind TMPDIR to the result of e.g. mktemp -d -p "${WORKSPACE}" .
Use a withEnv block to bind TMPDIR to WORKSPACE_TMP and then patch cleanWs() to delete all suffix directories (including WORKSPACE_TMP ) as some users have suggested in JENKINS-41805 (comment) , JENKINS-44909 , and JENKINS-50797 .
#1 seems simpler and safer to me, but I thought I'd check to see if you thought there were any arguments for #2. Gigabytes? I would say number 1. $WORKSPACE_TMP is intended for secrets, small text files needed temporarily to implement some step, etc.
Resolved in core for freestyle and similar builds; PR remains open for Pipeline.