Both tinderboxpushlog and the mercurial commit-hook needs to get the status of a particular tree. Currently this is currently only doable by either downloading http://tinderbox.mozilla.org/Firefox/ or http://tinderbox.mozilla.org/admintree.cgi?tree=Firefox The former is a gigantic 2MB file, the latter is a extremely slow loading, and still quite large 200kB file. It would be great if the status could be accessed separately through a dedicated url. It's quite possible that this uri will be hit a lot, so it might make sense to cache it in a static file or some such, but that might not be worth doing for now. Another important part is that the uri must server a Access-Control-Allow-Origin:* header so that it can be loaded by tbpl client side. For simplicity, I would say that no particular format is needed. Simply send the contents of the status textarea as it appears on admintree.cgi.

Reed points out that we already have http://tinderbox.mozilla.org/Firefox/status.pl But which isn't accessible to everyone at the moment (and probably doesn't send the Access-Control-Allow-Origin:* header)

http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox&quickparse=1 doesn't do what you want?

No - "status" as in tb_load_status(), the contents of the "Status message" textarea in admintree.

Something like this, perhaps?

Comment on attachment 490114 [details] [diff] [review] Patch v1 That will add a new endpoint to just return that item. I can imagine this will get a lot of calls so we should ask IT to add it to the tinderbox cache setup they have for slow changing endpoints. Asking rhelmer for a sanity check - simple tinderbox perl changes always make me worry

Doesn't the caching come from including it in http://mxr.mozilla.org/mozilla/source/webtools/tinderbox/showbuilds.pl#83 so that when anything changes, a static /Treename/status.html file will get regenerated?

(In reply to comment #6) > Doesn't the caching come from including it in > http://mxr.mozilla.org/mozilla/source/webtools/tinderbox/showbuilds.pl#83 so > that when anything changes, a static /Treename/status.html file will get > regenerated? Yes I believe that is how it works. I don't have a tinderbox server test environment set up right now, but patch looks good to me. Let's get it on tinderbox-stage :)

So should an entry be added to @pages to get a static page generated? The patch currently doesn't do that.

(In reply to comment #8) > So should an entry be added to @pages to get a static page generated? The patch > currently doesn't do that. Thanks, you're right; I shouldn't be reviewing this late.

Comment on attachment 490114 [details] [diff] [review] Patch v1 Please add a section to the @pages array, per comment 6. Something like this should do it: ['status.html', 'status'], Thanks phil/jonas for catching this.

Comment on attachment 490114 [details] [diff] [review] Patch v1 >Index: showbuilds.pl >=================================================================== >RCS file: /cvsroot/mozilla/webtools/tinderbox/showbuilds.pl,v >retrieving revision 1.44 (...) >+sub do_status($) { >+ my ($form_ref) = (@_); >+ if (!$form_ref->{static}) { >+ print "Content-Type: text/html; charset=utf-8\n"; >+ print "Access-Control-Allow-Origin: *\n\n"; >+ } One thing missing here - $tree is not defined. You can get it using: my $tree = $form_ref->{tree}; >+ my $status_message = &tb_load_status($tree); >+ $status_message =~ s:^\s*|\s*$::gs; >+ if ($status_message and length($status_message) gt 0) { >+ print "$status_message"; >+ } >+}

(In reply to comment #10) > Comment on attachment 490114 [details] [diff] [review] > Patch v1 > > Please add a section to the @pages array, per comment 6. Something like this > should do it: > > ['status.html', 'status'], Actually should be: ['status.html', 'do_status'], I've tested this change plus the fix in comment 6 in a local tinderbox instance and it seems to work as expected. Ms2ger can you please generate a new patch and r? bear, you have r+ from me with the changes above. I can retest and land it in CVS if you guys need, just let me know.

Done, thanks!

Tested this patch on my local tinderbox, seems to work as expected. After changing the status message on the admin page, I get a status.html and "status=1" param to showbuilds.cgi works as well (tried updating the message a few times). I see this header in the CGI output: Access-Control-Allow-Origin: * You may need IT to set this header for the status.html file in the Apache config on stage and prod. The below WFM in Apache 2 with the "headers" module loaded, and inside an appropriate Location directive: Header set Access-Control-Allow-Origin "*" I think this patch should be landed, and a followup bug should be filed for IT to update tinderbox-stage (like bug 601010) and set the above header. I don't have time to do either of these right now, but I can help with this early next week if no one else is able to sooner.

Checking in showbuilds.cgi; /cvsroot/mozilla/webtools/tinderbox/showbuilds.cgi,v <-- showbuilds.cgi new revision: 1.200; previous revision: 1.199 done Checking in showbuilds.pl; /cvsroot/mozilla/webtools/tinderbox/showbuilds.pl,v <-- showbuilds.pl new revision: 1.45; previous revision: 1.44 done

I'm getting a 404 for http://tinderbox.mozilla.org/Firefox/status.html Is that the wrong URL? Was the fix here somehow wrong or was the deployment in bug 612100 somehow wrong?

Similarly http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox&status=1 doesn't show just the status. Am I missing something?

Yes, you're missing the long slow path to production: bug 612100 deployed it at http://tinderbox-stage.mozilla.org/Firefox/status.html