scala / scala-dev

Scala 2 team issues. Not for user-facing bugs or directly actionable user-facing improvements. For build/test/infra and for longer-term planning and idea tracking. Our bug tracker is at https://github.com/scala/bug/issues
Apache License 2.0
130 stars 15 forks source link

PR validation builds on Jenkins failing with HTTP 413 codes ("too large") #827

Closed SethTisue closed 1 year ago

SethTisue commented 1 year ago

example: https://scala-ci.typesafe.com/job/scala-2.13.x-validate-main/16851/console

as noticed by @som-snytt

SethTisue commented 1 year ago

as I suspected, Artifactory is showing "90% Storage Space Reached: Your maximum storage limit has been reached. New artifact deployments are blocked until more disk space is added.", so there's your culprit right there

SethTisue commented 1 year ago

we've been here before: #636, #732

SethTisue commented 1 year ago

@lrytz can I punish you for your good deed in handling this last time, by asking you to handle it again?

SethTisue commented 1 year ago

(Lukas is working on it.)

lrytz commented 1 year ago

Cleaned out a bit more this time, in particular all of https://scala-ci.typesafe.com/ui/native/scala-release-temp.

Artifactory GC is still running, but we're already at 481.4 GB / 590.4 GB (81.5%).

The largest repo is scala-integration with 275 GB, it keeps a build for each merge. I think we should keep those, at least as long as there's other ways to make room.

The second largest is in fact not a repo with artifacts, but artifactory's internal derby database (/var/opt/jfrog/artifactory/data/derby) at 75 GB. I tried the Compress the Internal Database task, but it didn't seem to do anything. Will try again.

[edit: GC is done, we're at 452.6 GB / 590.4 GB (76.7%). "Compress the Internal Database" doesn't seem to do anything]