From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Richard Henderson" <richard.henderson@linaro.org>
Subject: Re: how long do we need to retain gitlab CI job stdout logs?
Date: Tue, 9 Aug 2022 09:50:22 +0100 [thread overview]
Message-ID: <YvIfzm+GWSEY28mO@redhat.com> (raw)
In-Reply-To: <536c6605-fd29-dbca-8633-944656e6dc8e@redhat.com>
On Mon, Aug 08, 2022 at 08:42:28PM +0200, Thomas Huth wrote:
> On 08/08/2022 19.47, Peter Maydell wrote:
> > Hi; I just reduced QEMU's storage usage on gitlab by 130GB (no typo!)
> > using https://gitlab.com/eskultety/gitlab_cleaner, which Dan helpfully
> > pointed me at. This script removes old pipelines, which take up a
> > lot of storage space for QEMU because they include the stdout logs
> > for all the CI jobs in the pipeline. (Gitlab doesn't expire these,
> > either by default or configurably -- you have to either manually delete
> > the pipeline in the UI or else use the API, as this script does.)
> >
> > I somewhat conservatively only blew away pipelines from before the
> > 1st January 2022. I feel like we don't really even need 6 months worth
> > of CI job logs, though -- any views on whether we should be pruning
> > them more aggressively ?
>
> I'd say we should at least keep the logs of the last 4 to 5 months, i.e. the
> logs for one release cycle, so we can check these logs in case we introduced
> a new bug in the current release cycle.
Have we ever actually done this in practice ? I don't think I've ever
looked at a pipeline older than 1-2 weeks in any project I've worked
with on gitlab.
Note that we currently use 165 GB, over an 8 month period (not sure on
the split between container registry and pipeline). I'd guess 4-5 months
might knock another 30-40 GB off our usage, still leaving it huge.
Personally I would suggest 1 month is sufficent for 99% of our needs.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2022-08-09 8:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-08 17:47 how long do we need to retain gitlab CI job stdout logs? Peter Maydell
2022-08-08 18:01 ` Warner Losh
2022-08-08 18:42 ` Thomas Huth
2022-08-09 6:15 ` Markus Armbruster
2022-08-09 8:50 ` Daniel P. Berrangé [this message]
2022-08-09 9:44 ` Markus Armbruster
2022-08-09 10:42 ` Daniel P. Berrangé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YvIfzm+GWSEY28mO@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.