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

removing a job (including multibranch/org folder branches/repos) does not remove the workspace

    XMLWordPrintable

    Details

    • Similar Issues:
    • Released As:
      2.0.21

      Description

      Removal of a job leaves the workspace intact.

        Attachments

          Issue Links

            Activity

            Hide
            jsoref Josh Soref added a comment -

            Jesse Glick this commit (https://github.com/jenkinsci/branch-api-plugin/commit/481e4857c9a450c2904ff5188aa9076cf1db1f1c) resulted in a fairly consistent but slightly random and mind boggling build failure.

            We just upgraded to Jenkins ver. 2.151 today (and upgraded all of our plugins at the same time).

            We were able to review our plugin update list and then sifted through commits. Eventually we settled on this one and fixed it by downgrading
            Branch API from 2.0.21 to 2.0.20 which effectively backed this out.

            We have a declarative Jenkinsfile pipeline file which uses parallel in a stage... It looks approximately like this. Note that We define an agent for the outer job and for Scala Full, but not for Frontend Prod. Frontend Prod builds happily (which means it can find the npm.sh file), Scala Full fails with an error trying to say that it can't find the sbt.sh file (these files all exist in a single git repository). If we pin all stages to a single node, it works. We're using the branch plugin to monitor pull requests from github and it's automagically building our commits based on that...

            pipeline {
                agent {
                    label "pipeline"
                }
            
                environment {
                    PIPELINE_SCRIPTS="$WORKSPACE/pipeline/scripts"
                    SBT_SCRIPT="$PIPELINE_SCRIPTS/sbt.sh"
                    NPM_SCRIPT="$PIPELINE_SCRIPTS/npm.sh"
                }
            
                stages {
                    stage ("Checkout") {
                        steps {
                            script {
                                result = sh (script: "git log -1 --pretty=format:'%an' | grep 'Jenkins'", returnStatus: true)
                                if (result != 0) {
                                    echo ("Non jenkins user commit")
                                }
                            }
                        }
                    }
            
                    stage("Compile") {
                        parallel {
                            stage("Scala Full") {
                                agent {
                                    label "pipeline"
                                }
                                steps {
                                    sh "$SBT_SCRIPT compile"
                                }
                            }
                            stage("Frontend Prod") {
                                steps {
                                    sh "$NPM_SCRIPT install"
                                }
                            }
                        }
                    }
                }
            }
            
            Show
            jsoref Josh Soref added a comment - Jesse Glick this commit ( https://github.com/jenkinsci/branch-api-plugin/commit/481e4857c9a450c2904ff5188aa9076cf1db1f1c ) resulted in a fairly consistent but slightly random and mind boggling build failure. We just upgraded to Jenkins ver. 2.151 today (and upgraded all of our plugins at the same time). We were able to review our plugin update list and then sifted through commits. Eventually we settled on this one and fixed it by downgrading Branch API from 2.0.21 to 2.0.20 which effectively backed this out. We have a declarative Jenkinsfile pipeline file which uses parallel in a stage... It looks approximately like this. Note that We define an agent for the outer job and for Scala Full, but not for Frontend Prod. Frontend Prod builds happily (which means it can find the npm.sh file), Scala Full fails with an error trying to say that it can't find the sbt.sh file (these files all exist in a single git repository). If we pin all stages to a single node, it works. We're using the branch plugin to monitor pull requests from github and it's automagically building our commits based on that... pipeline { agent { label "pipeline" } environment { PIPELINE_SCRIPTS= "$WORKSPACE/pipeline/scripts" SBT_SCRIPT= "$PIPELINE_SCRIPTS/sbt.sh" NPM_SCRIPT= "$PIPELINE_SCRIPTS/npm.sh" } stages { stage ( "Checkout" ) { steps { script { result = sh (script: "git log -1 --pretty=format: '%an' | grep 'Jenkins' " , returnStatus: true ) if (result != 0) { echo ( "Non jenkins user commit" ) } } } } stage( "Compile" ) { parallel { stage( "Scala Full" ) { agent { label "pipeline" } steps { sh "$SBT_SCRIPT compile" } } stage( "Frontend Prod" ) { steps { sh "$NPM_SCRIPT install" } } } } } }
            Hide
            jglick Jesse Glick added a comment -

            Uma Shankar sorry, I have no idea what is happening on your machine. You may want to install the Support Core plugin, which captures much richer diagnostics, and either attach a generated support bundle here or send it to me privately. (If attaching publicly, I recommend using the anonymization option, unless this is just a test server with no confidential projects.)

            Josh Soref I cannot even guess what might be causing your build failure. If you manage to narrow it down to a minimal, reproducible test case, please file a bug report and Link to it from here.

            Show
            jglick Jesse Glick added a comment - Uma Shankar sorry, I have no idea what is happening on your machine. You may want to install the Support Core plugin, which captures much richer diagnostics, and either attach a generated support bundle here or send it to me privately. (If attaching publicly, I recommend using the anonymization option, unless this is just a test server with no confidential projects.) Josh Soref I cannot even guess what might be causing your build failure. If you manage to narrow it down to a minimal, reproducible test case, please file a bug report and Link to it from here.
            Hide
            jglick Jesse Glick added a comment -

            A similar report in JENKINS-54654. Please use that for discussion.

            Show
            jglick Jesse Glick added a comment - A similar report in JENKINS-54654 . Please use that for discussion.
            Hide
            radiush Dariusz Daniłko added a comment - - edited

            Josh Soref: I would expect that if you specify nested 'pipeline' agent then the inner one should get a new workspace, which is why it does not have access to the git repo, which had been cloned to the workspace of the outer agent.

            You could get access to it if you `stash`ed the git repo after checkout and then `unstash`ed it in the nested pipeline stage.

            However, the pipeline does not look clean to me. What are you trying to achieve with such a nested pipeline anyway?

            Show
            radiush Dariusz Daniłko added a comment - - edited Josh Soref : I would expect that if you specify nested 'pipeline' agent then the inner one should get a new workspace, which is why it does not have access to the git repo, which had been cloned to the workspace of the outer agent. You could get access to it if you `stash`ed the git repo after checkout and then `unstash`ed it in the nested pipeline stage. However, the pipeline does not look clean to me. What are you trying to achieve with such a nested pipeline anyway?
            Hide
            jsoref Josh Soref added a comment -

            The nested agents do get their own git clones. The ones without a specified agent run on the same node as the main pipeline. I only need to use stash to share build products (omitted because it isn't relevant to the failure).

            Show
            jsoref Josh Soref added a comment - The nested agents do get their own git clones. The ones without a specified agent run on the same node as the main pipeline. I only need to use stash to share build products (omitted because it isn't relevant to the failure).

              People

              • Assignee:
                jglick Jesse Glick
                Reporter:
                bll6969 bll
              • Votes:
                90 Vote for this issue
                Watchers:
                94 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: