On Fri, Dec 13, 2019 at 8:20 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote:
On Fri, 2019-12-13 at 09:19 -0800, Kevin Fenzi wrote:
> It would be great if they could include the size +/- of all the images.
> Of course the most important ones would be boot.iso, workstation and
> server, but labs and spins could be very helpfull as well.
This sort of thing is what fedfind can help with. As an example of
where you'd start:
#!/bin/python3
import fedfind.release
import fedfind.helpers
rel = fedfind.release.get_release(cid="Fedora-Rawhide-20191213.n.0")
#rel = fedfind.release.get_release(1)
for img in rel.all_images:
imgid = fedfind.helpers.identify_image(img, out='string')
if img['disc_number'] > 1:
imgid += " disc {0}".format(img['disc_number'])
size = img.get('size')
if not size:
# this is something I should make fedfind handle...
# I swear it used to!
size = fedfind.helpers.get_size(img['direct_url'])
print("{0}: {1}".format(imgid, size))
hopefully it's pretty simple to see where to go from there. :) You can
try it with either of the 'rel' lines and it'll work...so you can
compare the image sizes from Fedora Core 1 with those from today's
Rawhide nightly, though they only have one image entirely in common
(Everything-boot-iso).
You can see I had to add a couple of bits to smoothly work with the
info for very old composes...I'll maybe tweak that a bit in fedfind
itself today, that code doesn't actually get *used* a lot so when I do
want to do something like this I usually find some issues that have
crept in.
This should work for any Pungi 4 compose that hasn't been garbage
collected yet, and also for all stable releases and old candidate
composes.
It...*could* also work for non-candidate (i.e. nightly) Pungi 4
composes that have been garbage collected by retrieving the info from
PDC, but this thread has made me realize that's a path that I've sort
of shut off with some design choices and I need to think about how to
open it up again.
That is really cool. And I'm aware of the compose report that goes to devel.
What I'm looking for is sizes of (and other info about) some specific use cases,
that we don't actually produce as artifacts. Like the httpd web server installed
on top of an image we produce, etc. They represent something that people
often install themselves as opposed us producing an image.
My goal is to detect changes that affect those use cases. It's conceptually
similar to some parts of the compose report, just looking at a different thing.
There is also one technical difference: Because we don't produce the use cases
as artifacts (we produce the very useful bits people can use to build those),
the service also needs to build them so it actually has something to look at.
So I prototyped the service to validate its usefulness. And I'd be happy to
throw away most of the code if something similar exists already — which was
the reason it's not really optimized.
Now I'm thinking if I could somehow use fedfind or the CI infrastructure for that...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
Adam Šamalík
---------------------------
Red Hat
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
