Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-39667

PIpeline job ignores custom workspace location

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      After last update (not sure which one, everything worked last time on 4. nov 2016) pipeline job began to use local jenkins directory (c:/Users/jenkins/.jenkins) for workspaces completely ignoring settings set under: "Manage Jenkins / Worspace Root DIrectory" and "Manage Jenkins / Build Record Root Directory", which are configured as follow:

      Workspace Root Directory = d:/jenkins/ws/$

      {ITEM_FULLNAME}/work
      Build Record Root Directory = d:/jenkins/ws/${ITEM_FULLNAME}

      /builds

        Attachments

          Issue Links

            Activity

            noodle_rebellion Dmitriy Belyaev created issue -
            noodle_rebellion Dmitriy Belyaev made changes -
            Field Original Value New Value
            Labels pipeline workspace
            Hide
            jglick Jesse Glick added a comment -

            If you are referring to multibranch Pipeline jobs (branch projects), this is intentional; see release notes for workflow-multibranch.

            Show
            jglick Jesse Glick added a comment - If you are referring to multibranch Pipeline jobs (branch projects), this is intentional; see release notes for workflow-multibranch .
            jglick Jesse Glick made changes -
            Resolution Won't Fix [ 2 ]
            Status Open [ 1 ] Resolved [ 5 ]
            Hide
            noodle_rebellion Dmitriy Belyaev added a comment -

            Jesse Glick I do understand that it will take some time for your to find a correct link, but referring to release note of workflow-multibranch plugin without any details does not help a lot. By reading latest changelog on the above named plugin I could not find any mention of workspace handling changes (changelog: https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Multibranch+Plugin).

            Show
            noodle_rebellion Dmitriy Belyaev added a comment - Jesse Glick I do understand that it will take some time for your to find a correct link, but referring to release note of workflow-multibranch plugin without any details does not help a lot. By reading latest changelog on the above named plugin I could not find any mention of workspace handling changes (changelog: https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Multibranch+Plugin ).
            Hide
            micheljung micheljung added a comment - - edited

            I don't understand how "this is intentional" is a justification for this unexpected and very problematic behavior. Unfortunately, I'm not able to find any explanation in the release notes either.

            Our project can't even be cloned because of this, making it impossible to use pipeline builds. And even if it wasn't problematic because of the path length:

            "As builds tend to be disk I/O intensive, changing this value enables you to put build workspaces on faster storage hardware, such as SSDs or even RAM disks."

            We don't get this with pipeline builds?

            Show
            micheljung micheljung added a comment - - edited I don't understand how "this is intentional" is a justification for this unexpected and very problematic behavior. Unfortunately, I'm not able to find any explanation in the release notes either. Our project can't even be cloned because of this, making it impossible to use pipeline builds. And even if it wasn't problematic because of the path length: "As builds tend to be disk I/O intensive, changing this value enables you to put build workspaces on faster storage hardware, such as SSDs or even RAM disks." We don't get this with pipeline builds?
            Hide
            jglick Jesse Glick added a comment -

            Use an agent and set the master to have zero executors.

            Show
            jglick Jesse Glick added a comment - Use an agent and set the master to have zero executors.
            jglick Jesse Glick made changes -
            Link This issue duplicates JENKINS-38837 [ JENKINS-38837 ]
            Hide
            zswanson Zach Swanson added a comment -

            This continues to be an issue - "use an agent" isn't an appropriate solution for setups where you only have 1 jenkins installation. Moreover, if the jenkins config has an option to set a workspace to a particular location than that location should be respected even on the master. The default location that Jenkins installs to on linux (redhat/centos at least) is /var/lib/jenkins. The /var partition is usually not very large!

            At the very least if you aren't going to do anything else, that config setting should be updated with a help note indicating that multibranch pipeline execution will ignore the setting. I would endorse though that if a single node is being used for jenkins and the master is both checking the pipeline and executing the builds that the location from the system config is respected.

            Show
            zswanson Zach Swanson added a comment - This continues to be an issue - "use an agent" isn't an appropriate solution for setups where you only have 1 jenkins installation. Moreover, if the jenkins config has an option to set a workspace to a particular location than that location should be respected even on the master. The default location that Jenkins installs to on linux (redhat/centos at least) is /var/lib/jenkins. The /var partition is usually not very large! At the very least  if you aren't going to do anything else, that config setting should be updated with a help note indicating that multibranch pipeline execution will ignore the setting. I would endorse though that if a single node is being used for jenkins and the master is both checking the pipeline and executing the builds that the location from the system config is respected.
            zswanson Zach Swanson made changes -
            Assignee Jesse Glick [ jglick ]
            Resolution Won't Fix [ 2 ]
            Status Resolved [ 5 ] Reopened [ 4 ]
            Hide
            jglick Jesse Glick added a comment -

            Dupe.

            Show
            jglick Jesse Glick added a comment - Dupe.
            jglick Jesse Glick made changes -
            Resolution Duplicate [ 3 ]
            Status Reopened [ 4 ] Resolved [ 5 ]
            Hide
            leemeador leemeador added a comment -

            "Use an agent" isn't an appropriate response for jobs that must be run on the master. For example, a backup job that backs up the master. For example, a monitoring job that checks for some problem on the master–configuration change, out of disk space, etc. For example, a build job that uses a plugin with a bug where it won't run on the agent.

            Once you allow these types of jobs to run on the master, some user can configure their build to run there for a while before you notice and make them move it. (This, of course, turns into disk space that would never be reused once you get them running on the agent.)

            Plus multibranch pipeline jobs use a workspace when there are shared libraries to load from SCM and some other situations.

            It works really well to move these jobs to a location on a different volume of the file system (as explained above)

            Finally, if there is no reason to move the workspace for multibranch pipeline jobs, there is also no reason to move other job types. All the considerations are the same except the multibranch pipeline jobs create more workspaces because there can be one for every branch. The other types of jobs don't create and discard workspaces as the branches are created and discarded.

            Show
            leemeador leemeador added a comment - "Use an agent" isn't an appropriate response for jobs that must be run on the master. For example, a backup job that backs up the master. For example, a monitoring job that checks for some problem on the master–configuration change, out of disk space, etc. For example, a build job that uses a plugin with a bug where it won't run on the agent. Once you allow these types of jobs to run on the master, some user can configure their build to run there for a while before you notice and make them move it. (This, of course, turns into disk space that would never be reused once you get them running on the agent.) Plus multibranch pipeline jobs use a workspace when there are shared libraries to load from SCM and some other situations. It works really well to move these jobs to a location on a different volume of the file system (as explained above) Finally, if there is no reason to move the workspace for multibranch pipeline jobs, there is also no reason to move other job types. All the considerations are the same except the multibranch pipeline jobs create more workspaces because there can be one for every branch. The other types of jobs don't create and discard workspaces as the branches are created and discarded.
            Hide
            noodle_rebellion Dmitriy Belyaev added a comment -

            I completely agree with Zach Swanson on:

            Moreover, if the jenkins config has an option to set a workspace to a particular location than that location should be respected even on the master.

            The plugin should respect global Jenkins settings and use its values.

            And Jesse Glick I was trying to avoid going onto personalities, but as one of the lead developers of this plugin, please stop marking this issues as RESOLVED or DUPLICATE and find some time to understand why it is not working for everyone (I think previous posters explained it in details already).

            Because currently all the communications can be shortly described as: "We decided it to be this way. Accept it or get lost."

            Show
            noodle_rebellion Dmitriy Belyaev added a comment - I completely agree with Zach Swanson on: Moreover, if the jenkins config has an option to set a workspace to a particular location than that location should be respected even on the master. The plugin should respect global Jenkins settings and use its values. And Jesse Glick I was trying to avoid going onto personalities, but as one of the lead developers of this plugin, please stop marking this issues as RESOLVED or DUPLICATE and find some time to understand why it is not working for everyone (I think previous posters explained it in details already). Because currently all the communications can be shortly described as: "We decided it to be this way. Accept it or get lost."
            noodle_rebellion Dmitriy Belyaev made changes -
            Description After last update (not sure which one, everything worked last time on 4. nov 2016) pipeline job began to use local jenkins directory (c:/Users/jenkins/.jenkins) for workspaces completely ignoring settings set under: "Manage Jenkins / Worspace Root DIrectory" and "Manage Jenkins / Build Record Root Directory", which are configured as follow:

            Workspace Root Directory = d:/jenkins/ws/${ITEM_FULLNAME}/work
            Build Record Root Directory = d:/jenkins/ws/${ITEM_FULLNAME}/builds
            After last update (not sure which one, everything worked last time on 4. nov 2016) pipeline job began to use local jenkins directory (c:/Users/jenkins/.jenkins) for workspaces completely ignoring settings set under: "Manage Jenkins / Worspace Root DIrectory" and "Manage Jenkins / Build Record Root Directory", which are configured as follow:

            Workspace Root Directory = d:/jenkins/ws/$

            \{ITEM_FULLNAME}/work
            Build Record Root Directory = d:/jenkins/ws/$\{ITEM_FULLNAME}

            /builds
            Hide
            jglick Jesse Glick added a comment -

            From the description it appears to be a duplicate of the known issue which was recently fixed, so you just need to update your plugins.

            Show
            jglick Jesse Glick added a comment - From the description it appears to be a duplicate of the known issue which was recently fixed, so you just need to update your plugins.
            Hide
            noodle_rebellion Dmitriy Belyaev added a comment -

            Jesse Glick oh, I see. I found this original issue and PR on it (which this defect duplicates). I will try to update my plugins. Thanks.

            Show
            noodle_rebellion Dmitriy Belyaev added a comment - Jesse Glick oh, I see. I found this original issue and PR on it (which this defect duplicates). I will try to update my plugins. Thanks.
            Hide
            akmjenkins ASHOK MOHANTY added a comment -

            Quick question.. We are using Jenkins 2.121.3 (& planning to upgrade to 2.164.3). Can I use custom workspace in Multibranch/Script pipeline !? 

            Show
            akmjenkins ASHOK MOHANTY added a comment - Quick question.. We are using Jenkins 2.121.3 (& planning to upgrade to 2.164.3). Can I use custom workspace in Multibranch/Script pipeline !? 
            Hide
            jglick Jesse Glick added a comment -

            Just use the dir or ws steps as needed.

            Show
            jglick Jesse Glick added a comment - Just use the dir or ws steps as needed.

              People

              Assignee:
              jglick Jesse Glick
              Reporter:
              noodle_rebellion Dmitriy Belyaev
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: