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

Matrix jobs default to "locked" (and are difficult to delete)

      With a matrix job now when it completes it defaults to being a "keep forever" type build. Only by deleting the current job can a previous job be deleted, in some cases.

      (09:36:12 AM) Tartarus: kohsuke: With matrix jobs and 1.418 I'm seeing all of my jobs default to being locked, didn't see this with 1.409, any ideas?
      (09:36:32 AM) kohsuke: probably related to the partial rebuild support. Any ticket for this?
      (09:36:54 AM) Tartarus: Hadn't filed one yet
      (09:37:18 AM) kohsuke: Would you please? I don't think I can get it right now, but I don't want to forget
      

          [JENKINS-10197] Matrix jobs default to "locked" (and are difficult to delete)

          Tom Rini created issue -

          Tom Rini added a comment -

          Just now when I had one build spinning up and I tried to delete the previous one it says that can't delete build #182 because #183 depends on it (roughly, forgot to copy in time).

          Tom Rini added a comment - Just now when I had one build spinning up and I tried to delete the previous one it says that can't delete build #182 because #183 depends on it (roughly, forgot to copy in time).

          Andrew Bayer added a comment -

          I ran into this a while back - the problem is that you've changed your axes, and now there's a chain of builds depending on each other back to the last one with the old axes. I got around this by deleting the actual directory from $JENKINS_HOME/jobs/$JOB_NAME/configurations/axis-label. That said, this is definitely still a real bug.

          Andrew Bayer added a comment - I ran into this a while back - the problem is that you've changed your axes, and now there's a chain of builds depending on each other back to the last one with the old axes. I got around this by deleting the actual directory from $JENKINS_HOME/jobs/$JOB_NAME/configurations/axis-label. That said, this is definitely still a real bug.

          Gary Yund added a comment -

          We have this issue as well. Because every build is kept and the logs are rather large, in approximately 2 months time, our logs are over 5GB for one job.

          Gary Yund added a comment - We have this issue as well. Because every build is kept and the logs are rather large, in approximately 2 months time, our logs are over 5GB for one job.

          Barry Wark added a comment -

          Also experiencing the same issue, and we're quickly filling up disk space on our master. Since we've saved release builds in the artifacts of jobs, I can't just delete the entire jobs/$JOB_NAME/configurations/axis-label folder (though I'll start working through and copying the artifacts out so that we can). Has anyone figured out how to delete particular builds when they're in this "locked" state?

          Barry Wark added a comment - Also experiencing the same issue, and we're quickly filling up disk space on our master. Since we've saved release builds in the artifacts of jobs, I can't just delete the entire jobs/$JOB_NAME/configurations/axis-label folder (though I'll start working through and copying the artifacts out so that we can). Has anyone figured out how to delete particular builds when they're in this "locked" state?

          I have this problem too....

          I'm wondering if it's related to JENKINS-10131 - Git Plugin kicks off builds for executors.

          All the builds that are having this issue are triggered by git looking for workspaces. I don't know if that's the case with the other builds.

          Christian Höltje added a comment - I have this problem too.... I'm wondering if it's related to JENKINS-10131 - Git Plugin kicks off builds for executors. All the builds that are having this issue are triggered by git looking for workspaces. I don't know if that's the case with the other builds.

          Barry Wark added a comment -

          Although we have the git plugin installed, all of the relevant builds are from SVN.

          Barry Wark added a comment - Although we have the git plugin installed, all of the relevant builds are from SVN.

          Tom Rini added a comment -

          I've ran a git bisect on this problem and it's:

          51c85a9fa030013553299e59649251b4f09560d5 is the first bad commit
          commit 51c85a9fa030013553299e59649251b4f09560d5
          Author: Kohsuke Kawaguchi <kk@kohsuke.org>
          Date: Thu May 12 10:50:18 2011 -0700

          control GC so that records are always full

          Tom Rini added a comment - I've ran a git bisect on this problem and it's: 51c85a9fa030013553299e59649251b4f09560d5 is the first bad commit commit 51c85a9fa030013553299e59649251b4f09560d5 Author: Kohsuke Kawaguchi <kk@kohsuke.org> Date: Thu May 12 10:50:18 2011 -0700 control GC so that records are always full
          Tom Rini made changes -
          Assignee New: Kohsuke Kawaguchi [ kohsuke ]

          Yeah, that isPartial() function looks wrong....

          Christian Höltje added a comment - Yeah, that isPartial() function looks wrong....

            vjuranek vjuranek
            tomrini Tom Rini
            Votes:
            24 Vote for this issue
            Watchers:
            37 Start watching this issue

              Created:
              Updated:
              Resolved: