From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 7C1C13971C69 for ; Fri, 25 Sep 2020 17:02:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7C1C13971C69 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-389-yAGreqeoMCiZeyFhkkS1gA-1; Fri, 25 Sep 2020 13:02:08 -0400 X-MC-Unique: yAGreqeoMCiZeyFhkkS1gA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3ACC01084C87 for ; Fri, 25 Sep 2020 17:02:07 +0000 (UTC) Received: from theo.uglyboxes.com (ovpn-113-168.phx2.redhat.com [10.3.113.168]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 17B6E6198B for ; Fri, 25 Sep 2020 17:02:07 +0000 (UTC) Subject: Re: [RFC PATCH] New script `summarize' To: Bunsen References: <20200924185424.1496842-1-keiths@redhat.com> <23de1a72-0feb-4937-95a3-07d185e44b02@www.fastmail.com> From: Keith Seitz Message-ID: <8e8ee2f3-95ef-8009-7a8f-cb00b6f827e1@redhat.com> Date: Fri, 25 Sep 2020 10:02:06 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <23de1a72-0feb-4937-95a3-07d185e44b02@www.fastmail.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-13.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: bunsen@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Bunsen mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2020 17:02:11 -0000 On 9/25/20 8:07 AM, Serhei Makarov wrote: >> diff --git a/bunsen.py b/bunsen.py >> index b089d80..99c4cc0 100755 >> --- a/bunsen.py >> +++ b/bunsen.py >> @@ -622,6 +622,34 @@ class Testrun(dict): >> # XXX Set summary=False if JSON was missing testcases. >> self.summary = self.summary and 'testcases' in json_data >> >> + # Return properties of this Testrun as printable strings, or > Suggest "Return configuration properties" > for consistency with other code/comments that use the term 'configuration' > for these properties. Changed. >> + # "" if unknown. Returns a dictionary containing >> + # keys for architecture, board, branch, version. >> + >> + def get_info_strings(self): >> + info = dict() >> + if 'arch' in self: >> + info['architecture'] = self.arch >> + else: >> + info['architecture'] = '' >> + >> + if 'board' in self: >> + info['board'] = self.board >> + else: >> + info['board'] = '' >> + >> + if 'source_branch' in self: >> + info['branch'] = self.source_branch >> + else: >> + info['branch'] = '' >> + >> + if 'version' in self: >> + info['version'] = self.version >> + else: >> + info['version'] = '' >> + >> + return info >> + > Looks OK to me, I may simplify or generalize this code with a later > patch. (e.g. by taking a dictionary of field name -> display name as > an optional argument, or having that dictionary predefined somewhere > and defaulting to return all the keys/values that are *not* specific > to the Bunsen storage (such as bunsen_commit_id) -- needs some > thinking on my part, so please commit as-is for now).> > It's worth noting that the set of configuration keys will vary by project, > e.g. for SystemTap 'osver' (the Linux distribution) is a more important field. > Yes, please do whatever is necessary/efficient/clean. These are currently the properties that I "need" in order to rule the wo^W^W^W satisfy my use case. I'm still getting my proverbial legs with python, so there are almost certainly better, more pythony ways to do this, I am sure. > LGTM. Pushed with your suggested changes. Thank you! Keith