On Wed, 2019-09-18 at 08:29 -0700, Adam Williamson wrote: > On Tue, 2019-09-17 at 17:38 -0600, Chris Murphy wrote: > > On Tue, Sep 17, 2019 at 2:35 PM Ben Cotton <bcotton@xxxxxxxxxx> wrote: > > > > > I like this approach better than just moving the criterion to Final > > > because in cases of large overages, the package gymnastics that might > > > be required to make it work could prove to be pretty impactful. I'd > > > have a lot more confidence in our ability to deliver a good experience > > > to our users if we're trying to trim half a gig from an image before > > > Beta than if we're doing it on the Monday before Go/No-Go. > > > > From Go/No-Go > > 17:16:12 <adamw> i mean, technically we knew about it, the script has > > been filing the results in the wiki religiously > > 17:16:17 <adamw> we just sort of forgot to notice and file a bug > > > > Is it possible for this script, or Pungi, to grow the ability to file > > a bug or send email to the responsible party? > > It's possible, it's just a bit awkward to implement (dealing with > Bugzilla authentication probably the most awkward bit, I'd have to talk > to a couple of people about how we do that). I'd much prefer the bug > filing option over the email sending option, as email has a way of > being ignored sometimes. > > The implementation here is actually a fairly 'dumb' thing - what > happens is just that the fedora-messaging consumer that creates the > validation events, relvalconsumer, just flat out calls 'relval size- > check' on the compose after it's done creating the event. So to enhance > that I'd probably give relval an option to file bugs when doing the > size-check operation and have relvalconsumer toggle that option on; as > mentioned the tricky part would just be in figuring out what's > necessary to ensure the system where it runs is always authenticated to > Bugzilla, we'd need a persistent auth token for it or something. So, I pretty much wrote this today: https://pagure.io/fedora-qa/relval/c/04a9b9e0227c14dc8627fa3a85ea177707ab9cf5?branch=size-check-bz and it works: https://partner-bugzilla.redhat.com/show_bug.cgi?id=F31Workstationlivex86_64Oversize Thanks to Kevin Fenzi and Jeff Fearn we should also be able to work out the auth stuff, so I should be able to deploy this to production fairly soon, I hope. It basically works off aliases: for each checked image there's a unique alias per release. If an image is oversize it figures out the alias, and looks to see if there's a bug with that alias already. If there is, it adds a comment and sets the bug status to ASSIGNED (this could nerf an ON_QA or MODIFIED occasionally, but it's no big deal, we can manually set it back). If there isn't a bug with that alias already, it files a new one, and if the image is a blocking one, it sets the bug to block both the Beta and Final blocker trackers for the relevant release (this is because there is no good programmatic way to tell whether we're actually in Beta or Final phase, so the idea is that a human will correct this after the bug pops up on our radar; since this is only done on bug *creation*, it shouldn't be too onerous). It always files against component 'distribution' because I didn't feel like writing an awful mapping of image identifiers to Bugzilla components, but at least since it marks blocker image bugs as blocking the trackers, we will notice those bugs. For the record, it makes me sad that we don't have a good way to know whether we're in Beta or Final phase, and also that the canonical definition of 'blocking' images and image target sizes is just a wiki page, and thus not reasonably consumable by code (so this code just duplicates and will need manually updating if the list of blocking images changes)... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
