Discussion about current and future development plans for the Beaker project ()

Bill Peck | 4 Jan 2010 22:36

Picon

updated spec file


Hello Everyone,

I've updated the beaker spec file to do some magic with regard to git.  
If you have a branch checked out and do a make snaparchive and then a 
make srpm or rpm it will have the timestamp and branch name in the release.

for example:

/home/bpeck/Sandbox/Beaker/rpm-build/beaker-0.4.71-0.1262640463.ticket51.el5.src.rpm

But if you do the same from master it will just be:

/home/bpeck/Sandbox/Beaker/rpm-build/beaker-0.4.71-0.el5.src.rpm

This allows for really easy testing of branches without needing to 
update the spec file and check that into git.  Which is always a pain 
because it will no doubt conflict with master when you try and merge it 
later.

I also created a subpackage called beaker which only contains 
beaker/__init__.py with __version__ = '0.4.71' in it.  The idea is to 
update the web templates to display this version on the web page and 
possibly pre-populate a bugzilla url with the right version.

Let me know if you have any questions or see any problems.

Raymond Mancy | 5 Jan 2010 03:02

Picon

Re: updated spec file


----- "Bill Peck" <bpeck <at> redhat.com> wrote:

> From: "Bill Peck" <bpeck <at> redhat.com>
> To: "List for the development of the Beaker project" <beaker-devel <at> lists.fedorahosted.org>
> Sent: Tuesday, January 5, 2010 7:36:47 AM GMT +10:00 Brisbane
> Subject: [Beaker-devel] updated spec file
>
> Hello Everyone,
> 
> I've updated the beaker spec file to do some magic with regard to git.
>  
> If you have a branch checked out and do a make snaparchive and then a
> 
> make srpm or rpm it will have the timestamp and branch name in the
> release.
> 
> for example:
> 
> /home/bpeck/Sandbox/Beaker/rpm-build/beaker-0.4.71-0.1262640463.ticket51.el5.src.rpm
>

I seem to be having a problem with this. From the master branch I do the following

git branch bz537414
git checkout bz537414
*edit stuff*
*git add and commit*
make snaparchive
make rpm

(Continue reading)

Bill Peck | 5 Jan 2010 15:11

Picon

Re: updated spec file

On 01/04/2010 09:02 PM, Raymond Mancy wrote:
> ----- "Bill Peck"<bpeck <at> redhat.com>  wrote:
>
>    
>> From: "Bill Peck"<bpeck <at> redhat.com>
>> To: "List for the development of the Beaker project"<beaker-devel <at> lists.fedorahosted.org>
>> Sent: Tuesday, January 5, 2010 7:36:47 AM GMT +10:00 Brisbane
>> Subject: [Beaker-devel] updated spec file
>>
>> Hello Everyone,
>>
>> I've updated the beaker spec file to do some magic with regard to git.
>>
>> If you have a branch checked out and do a make snaparchive and then a
>>
>> make srpm or rpm it will have the timestamp and branch name in the
>> release.
>>
>> for example:
>>
>> /home/bpeck/Sandbox/Beaker/rpm-build/beaker-0.4.71-0.1262640463.ticket51.el5.src.rpm
>>
>>      
> I seem to be having a problem with this. From the master branch I do the following
>
> git branch bz537414
> git checkout bz537414
> *edit stuff*
> *git add and commit*
> make snaparchive

(Continue reading)

Bill Peck | 5 Jan 2010 15:28

Picon

Re: updated spec file

On 01/05/2010 09:11 AM, Bill Peck wrote:
> On 01/04/2010 09:02 PM, Raymond Mancy wrote:
>    
>> ----- "Bill Peck"<bpeck <at> redhat.com>   wrote:
>>
>>
>>      
>>> From: "Bill Peck"<bpeck <at> redhat.com>
>>> To: "List for the development of the Beaker project"<beaker-devel <at> lists.fedorahosted.org>
>>> Sent: Tuesday, January 5, 2010 7:36:47 AM GMT +10:00 Brisbane
>>> Subject: [Beaker-devel] updated spec file
>>>
>>> Hello Everyone,
>>>
>>> I've updated the beaker spec file to do some magic with regard to git.
>>>
>>> If you have a branch checked out and do a make snaparchive and then a
>>>
>>> make srpm or rpm it will have the timestamp and branch name in the
>>> release.
>>>
>>> for example:
>>>
>>> /home/bpeck/Sandbox/Beaker/rpm-build/beaker-0.4.71-0.1262640463.ticket51.el5.src.rpm
>>>
>>>
>>>        
>> I seem to be having a problem with this. From the master branch I do the following
>>
>> git branch bz537414

(Continue reading)

Raymond Mancy | 5 Jan 2010 23:47

Picon

Re: updated spec file


----- "Bill Peck" <bpeck <at> redhat.com> wrote:

> From: "Bill Peck" <bpeck <at> redhat.com>
> To: beaker-devel <at> lists.fedorahosted.org
> Sent: Wednesday, January 6, 2010 12:11:51 AM GMT +10:00 Brisbane
> Subject: Re: [Beaker-devel] updated spec file
>
> On 01/04/2010 09:02 PM, Raymond Mancy wrote:
> > ----- "Bill Peck"<bpeck <at> redhat.com>  wrote:
> >
> >    
> >> From: "Bill Peck"<bpeck <at> redhat.com>
> >> To: "List for the development of the Beaker
> project"<beaker-devel <at> lists.fedorahosted.org>
> >> Sent: Tuesday, January 5, 2010 7:36:47 AM GMT +10:00 Brisbane
> >> Subject: [Beaker-devel] updated spec file
> >>
> >> Hello Everyone,
> >>
> >> I've updated the beaker spec file to do some magic with regard to
> git.
> >>
> >> If you have a branch checked out and do a make snaparchive and then
> a
> >>
> >> make srpm or rpm it will have the timestamp and branch name in the
> >> release.
> >>
> >> for example:

(Continue reading)

Bill Peck | 5 Jan 2010 23:52

Picon

Re: updated spec file

On 01/05/2010 05:47 PM, Raymond Mancy wrote:
> ----- "Bill Peck"<bpeck <at> redhat.com>  wrote:
>
>    
>> From: "Bill Peck"<bpeck <at> redhat.com>
>> To: beaker-devel <at> lists.fedorahosted.org
>> Sent: Wednesday, January 6, 2010 12:11:51 AM GMT +10:00 Brisbane
>> Subject: Re: [Beaker-devel] updated spec file
>>
>> On 01/04/2010 09:02 PM, Raymond Mancy wrote:
>>      
>>> ----- "Bill Peck"<bpeck <at> redhat.com>   wrote:
>>>
>>>
>>>        
>>>> From: "Bill Peck"<bpeck <at> redhat.com>
>>>> To: "List for the development of the Beaker
>>>>          
>> project"<beaker-devel <at> lists.fedorahosted.org>
>>      
>>>> Sent: Tuesday, January 5, 2010 7:36:47 AM GMT +10:00 Brisbane
>>>> Subject: [Beaker-devel] updated spec file
>>>>
>>>> Hello Everyone,
>>>>
>>>> I've updated the beaker spec file to do some magic with regard to
>>>>          
>> git.
>>      
>>>> If you have a branch checked out and do a make snaparchive and then

(Continue reading)

Raymond Mancy | 7 Jan 2010 06:48

Picon

Alternative to disable custom columns.

Hi Bill, Just wanting your thoughts on a good alternative to the disable result column checkbox on ticket51.

The only reasonable alternative I can come up with is the following.

Initially, in the checkbox list of result columns, have our default columns selected (System,Status,Vendor...etc).
Have another link up the top that allows them to populate that checkbox list with only default values (so they
can easily go from a heavily customised result set back to the default).

I'm trying to make it easy for the user to go between a customised search result and a default search result.
If 
they wanted to go between the two quite often it could get fiddley if they had to do it all manually. Maybe I'm 
overstating this feature though.

Raymond

Bill Peck | 7 Jan 2010 19:46

Picon

Re: Alternative to disable custom columns.

On 01/07/2010 12:48 AM, Raymond Mancy wrote:
> Hi Bill, Just wanting your thoughts on a good alternative to the disable result column checkbox on ticket51.
>
> The only reasonable alternative I can come up with is the following.
>
> Initially, in the checkbox list of result columns, have our default columns selected (System,Status,Vendor...etc).
> Have another link up the top that allows them to populate that checkbox list with only default values (so they
> can easily go from a heavily customised result set back to the default).
>
> I'm trying to make it easy for the user to go between a customised search result and a default search result. If
> they wanted to go between the two quite often it could get fiddley if they had to do it all manually. Maybe I'm
> overstating this feature though.
>
>
> Raymond
>
>
>
>    

Hi Raymond,

Here are my thoughts on testing ticket51 so far.

- Default to having all current columns selected. (The ones we normally 
show)
- Have three "shortcut" links, Select All, Select None, and Select Default.
     - move these to under the checkbox div.  I don't think we want to 
see them unless we are actually clicking and unclicking checkboxes.  
Users will be confused otherwise.

(Continue reading)

Raymond Mancy | 7 Jan 2010 23:23

Picon

Re: Alternative to disable custom columns.


----- "Bill Peck" <bpeck <at> redhat.com> wrote:

> From: "Bill Peck" <bpeck <at> redhat.com>
> To: "Raymond Mancy" <rmancy <at> redhat.com>
> Cc: "beaker-devel" <beaker-devel <at> lists.fedorahosted.org>
> Sent: Friday, January 8, 2010 4:46:57 AM GMT +10:00 Brisbane
> Subject: Re: Alternative to disable custom columns.
>
> On 01/07/2010 12:48 AM, Raymond Mancy wrote:
> > Hi Bill, Just wanting your thoughts on a good alternative to the
> disable result column checkbox on ticket51.
> >
> > The only reasonable alternative I can come up with is the
> following.
> >
> > Initially, in the checkbox list of result columns, have our default
> columns selected (System,Status,Vendor...etc).
> > Have another link up the top that allows them to populate that
> checkbox list with only default values (so they
> > can easily go from a heavily customised result set back to the
> default).
> >
> > I'm trying to make it easy for the user to go between a customised
> search result and a default search result. If
> > they wanted to go between the two quite often it could get fiddley
> if they had to do it all manually. Maybe I'm
> > overstating this feature though.
> >
> >

(Continue reading)

Marian Csontos | 8 Jan 2010 22:01

Picon

Re: result_upload_file, handling attachments and other relationships

Hi Bill,

rhts uses "late binding" - it uploads a file and only then would say it 
was resultLog.

I would like to avoid caching files in backends,
and I would like to go on (at least for a while) with original 
rhts-devel-test-env and submit all patches upstream. At least while it 
will be used by the two systems.

Fortunately rhts is under our control and the change is simple enough - 
requires only to change report_log function in rhts-db-submit-result:
+      bkr = beaker()
+      if bkr:
+          resp = session.results.resultLog(log_type, result_id, prettyname)
        rhts.uploadWrapper(session,log_name,recipetestid, prettyname)
-      resp = session.results.resultLog(log_type, result_id, prettyname)
+      if not bkr:
+          resp = session.results.resultLog(log_type, result_id, prettyname)
...and...
+def beaker():
+    return os.environ.get('FROM_BEAH')

Any advice on this particular solution?

However, we might run into situation, where it will not be that easy.
Do you think it would be possible to change server in such case?

I would like to suggest a change on server: I see no need to 
differentiate between {task,recipe,result}_upload_file - it is just a

(Continue reading)

Group

gmane.comp.systems.beaker.devel.

Project Web Page

Discussion about current and future development plans for the Beaker project ()

Search Archive

Page

1 | 2 | 3 | 4

Articles in period: 32

January 2010

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane

Recent entries

Beaker road map updated (20 May 2013)
The march towards Beaker 1.0 (13 May 2013)
Defining a more useful component list in Bugzilla (13 May 2013)
Handling exit status of the commands execution from all the nodes (7 May 2013)
Technical roadmap updated (3 May 2013)
Patch merge criteria documented (3 May 2013)
Revised Enhanced User Group proposal on Gerrit (30 Apr 2013)
Clarification request for Enhanced User Groups (30 Apr 2013)
Beaker 0.12 released (24 Apr 2013)
New Beaker API quirks (28 Mar 2013)
Notify Job owner before triggering test system scraping (22 Mar 2013)
status of inventory using lshw? (18 Mar 2013)
System pools design proposal updated (11 Mar 2013)
Limited availability - March 12 -> April 8th (11 Mar 2013)
Draft release notes page and backfilled release notes for 0.11! (7 Mar 2013)
Enhanced User Groups design proposal updated (7 Mar 2013)
Slight change to release notes process (27 Feb 2013)
Beaker-project.org updated (26 Feb 2013)
Reorganising Power tab (26 Feb 2013)
Harness API proposal (21 Feb 2013)
Harness API proposal (20 Feb 2013)

Archives

13	May 2013
15	April 2013
23	March 2013
69	February 2013
25	January 2013
14	December 2012
12	November 2012
12	October 2012
1	August 2012
3	July 2012
4	January 2012
4	December 2011
3	November 2011
2	October 2011
3	September 2011
6	August 2011
10	July 2011
7	June 2011
18	May 2011
40	April 2011
1	March 2011
1	November 2010
1	October 2010
5	September 2010
6	August 2010
2	July 2010
8	May 2010
16	April 2010
10	March 2010
7	February 2010
32	January 2010
20	December 2009
19	November 2009
1	October 2009
3	August 2009
9	July 2009
32	June 2009
19	May 2009
18	April 2009
31	March 2009
20	February 2009

Design

Zawodny | Right Menu | Left Menu

Your Own Design

Paste the URL of your CSS below. Download CSS template