From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Cc: qemu-devel@nongnu.org,
"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
"Thomas Huth" <thuth@redhat.com>,
"Beraldo Leal" <bleal@redhat.com>,
"Alex Benné e" <alex.bennee@linaro.org>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>
Subject: Re: [PATCH 0/2] gitlab: expose installed package info in build logs
Date: Thu, 25 Jul 2024 11:00:56 +0100 [thread overview]
Message-ID: <ZqIiWH3XPsUJNAEG@redhat.com> (raw)
In-Reply-To: <h6b6l.5yloo5aflex@linaro.org>
On Thu, Jul 25, 2024 at 12:42:18PM +0300, Manos Pitsidianakis wrote:
> Hello Daniel,
>
> On Wed, 24 Jul 2024 12:55, "Daniel P. Berrangé" <berrange@redhat.com> wrote:
> > Many times we see a build job start failing, we wonder if the installed
> > packages have changed since the last passing build. We can rarely
> > diagnose this, however, since we only have the new container image, not
> > the old one.
> >
>
> APT allows you to specify to pin package versions when installing; wouldn't
> that help ensure our tests are deterministic?
We want to be testing against latest packages because that reflects
what our users are likely to see on their own systems. IOW, having
failures after newly updated packages is a good thing - provided we
can easily identify what caused the breakage, to enable us to fix
it promptly - by promptly I mean same-day.
> Furthermore, a gitlab cron job pipeline can be set up to run every e.g. few
> months and inform of any updates so that we can manually bump them.
Only seeing breakage from new packages as long as a few months after it
happens is a bad thing. We benefit from fast detection and fast fixing.
In cases where the new package is broken, rather than QEMU, it is also
better to be able to report that back to the distro within days of them
rolling out the problem as it'll be fresh in their minds to fix.
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:[~2024-07-25 10:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-24 9:55 [PATCH 0/2] gitlab: expose installed package info in build logs Daniel P. Berrangé
2024-07-24 9:55 ` [PATCH 1/2] gitlab: record installed packages in /packages.txt in containers Daniel P. Berrangé
2024-07-24 9:55 ` [PATCH 2/2] gitlab: display /packages.txt in build jobs Daniel P. Berrangé
2024-07-24 11:14 ` [PATCH 0/2] gitlab: expose installed package info in build logs Alex Bennée
2024-07-25 7:06 ` Philippe Mathieu-Daudé
2024-07-25 9:42 ` Manos Pitsidianakis
2024-07-25 9:56 ` Thomas Huth
2024-07-25 10:20 ` Manos Pitsidianakis
2024-07-25 10:00 ` Daniel P. Berrangé [this message]
2024-07-25 10:14 ` Alex Bennée
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=ZqIiWH3XPsUJNAEG@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=bleal@redhat.com \
--cc=manos.pitsidianakis@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
--cc=wainersm@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).