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

workspace/<jobname>* are not cleaned on SCM change.

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: workflow-job-plugin
    • Labels:
      None
    • Environment:
      jenkins 2.89.3, pipeline 2.5, git 3.7.0
    • Similar Issues:

      Description

      When changing a Pipeline job from a Pipeline Perforce to a Pipeline git (just changing the SCM type) the workspace/<jobname>* files and dirs should be cleaned up.

      Why? Because on the change from P4 -> Git, we can observe the following behaviour:

      Setup, Do an admin-like thing and make a git backup of your jenkins master home :

      cd into the Jenkins home directory (e.g., /var/lib/jenkins);
      git init && git add . && git commit -m `initial commit`

      Create a Pipeline job that pulls from Perforce to run a Jenkinsfile. Have it run once.
      Now change the Pipeline job to pull from Git (pretend you migrated your code or something).
      Run the job. Now see that most of the jenkins home is blown away.

      This is because when git encounters problems, git will traverse upwards looking for some usable .git directory. It will wind up in your jenkins home.

      The workaround, is that git or jenkins or pipeline should set "GIT_CEILING_DIRECTORIES" to prevent git from leaving the workspace directory. And cleanup the workspace/<jobname>* (@script in particular) on SCM change.

        Attachments

          Issue Links

            Activity

            Hide
            mhall4 Matthew Hall added a comment -

            Just so you know, any person with 'job change' permissions, and a jenkins server with config files stored in .git in $JENKINS_HOME, that user can effectively destroy/DOS the jenkins instance. Maybe someone will do something with this bug, because it's kind of dangerous.

            Show
            mhall4 Matthew Hall added a comment - Just so you know, any person with 'job change' permissions, and a jenkins server with config files stored in .git in $JENKINS_HOME, that user can effectively destroy/DOS the jenkins instance. Maybe someone will do something with this bug, because it's kind of dangerous.

              People

              • Assignee:
                Unassigned
                Reporter:
                mhall4 Matthew Hall
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated: