Closed
Bug 875559
Opened 11 years ago
Closed 11 years ago
publish bors status queue
Categories
(Release Engineering :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: bhearsum, Assigned: bhearsum)
References
Details
Attachments
(2 files, 1 obsolete file)
13.92 KB,
patch
|
dustin
:
review+
bhearsum
:
checked-in+
|
Details | Diff | Splinter Review |
1004 bytes,
patch
|
dustin
:
review+
bhearsum
:
checked-in+
|
Details | Diff | Splinter Review |
This patch installs the files required to show the Bors status queue on the Buildbot WebStatus, and sets up a cronjob to regularly copy it there. It also refactors the toplevel modules a bit to give the Servo buildbot master+bors installation a single toplevel node - I think I read somewhere or someone told me that this is preferred. Haven't tested it yet because I can't get the test env working on servo-puppet1 =(.
Attachment #753534 -
Flags: review?(dustin)
Comment 1•11 years ago
|
||
Comment on attachment 753534 [details] [diff] [review] publish bors status Review of attachment 753534 [details] [diff] [review]: ----------------------------------------------------------------- This looks pretty good, with just a few minor changes, but r- because it's not ready to land as-is. Globally -- and I've missed this on previous reviews -- all files need MPL copyright headers. If the JS comes from somewhere else, then that should be annotated too. ::: modules/bors/files/bors-render.js @@ +49,5 @@ > + who + " " + when + " #" + e["num_comments"], > + "commentheader")); > + c.appendChild(elt_txt_class("div", what, "commentbody")); > + td.appendChild(c); > + lots of trailing whitespace here.. ::: modules/bors/manifests/cron.pp @@ +1,1 @@ > +define bors::cron($basedir, $owner, $status_location) { why does bors::cron need the status locatoin? ::: modules/bors/manifests/status.pp @@ +3,5 @@ > + "${status_location}": > + owner => $owner, > + group => $group, > + mode => 755, > + ensure => directory; This should probably depend on the buildmaster being set up somehow. Ideally, that would be requires => Class['buildmaster'] or something of that sort. That may require using some Anchor resource to ensure it works. @@ +19,5 @@ > + owner => $owner, > + group => $group, > + mode => 644, > + source => "puppet:///modules/bors/bors-render.js"; > + "${status_location}/bors-render.js": Duplicate resource
Attachment #753534 -
Flags: review?(dustin) → review-
Assignee | ||
Comment 2•11 years ago
|
||
(In reply to Dustin J. Mitchell [:dustin] from comment #1) > ::: modules/bors/manifests/cron.pp > @@ +1,1 @@ > > +define bors::cron($basedir, $owner, $status_location) { > > why does bors::cron need the status locatoin? Because there's a cronjob that copies a file to $status_location. That's in bors-cron.erb, and I think I need the variable here in order for it to be accessible to that file... > ::: modules/bors/manifests/status.pp > @@ +3,5 @@ > > + "${status_location}": > > + owner => $owner, > > + group => $group, > > + mode => 755, > > + ensure => directory; > > This should probably depend on the buildmaster being set up somehow. > Ideally, that would be requires => Class['buildmaster'] or something of that > sort. That may require using some Anchor resource to ensure it works. It seems wrong to for Bors module to assume that it will be interacting with Buildbot (because eg, it could be replaced with Jenkins or something else). Doesn't Bors::Instance["servo"] requiring Buildmaster::Buildbot_master::Servo["bms01-servo1"] cover this?
Assignee | ||
Comment 3•11 years ago
|
||
Also, the bors js/css/html comes from a private github repo...how should I be annotating those files? Seems pointless to link to the repo.
Comment 4•11 years ago
|
||
A private repo, eh? Yet, we're distributing it publicly? What's the story there? Is that private repo under the MPL? Fair enough regarding the cronjob. A comment might help someone else (or me, later) avoid confusion. As for the dependency, it might be taken care of by the automatic dependencies of File resources on their parents. I don't think the require will help - they're not as transitive as one hopes (so it will only make sure that the Bors::Instance resource is evaluated before the buildmaster, but not anything that the Bors::Instance resource requires -- that's what Anchors can fix). If not, it just means that you run puppet twice, and add anchors later. So those issues are fine. The duplicate-resource and copyright-header issues stand.
Assignee | ||
Comment 5•11 years ago
|
||
(In reply to Dustin J. Mitchell [:dustin] from comment #4) > A private repo, eh? Yet, we're distributing it publicly? What's the story > there? Is that private repo under the MPL? Heh, good point. It's not actually private code. Graydon originally put it in a private repo in hopes that it would reduce hoops he had to jump through when setting it up for Rust. There's no license attached to any of the upstream code. > > As for the dependency, it might be taken care of by the automatic > dependencies of File resources on their parents. I don't think the require > will help - they're not as transitive as one hopes (so it will only make > sure that the Bors::Instance resource is evaluated before the buildmaster, > but not anything that the Bors::Instance resource requires -- that's what > Anchors can fix). If not, it just means that you run puppet twice, and add > anchors later. Ah, OK. > So those issues are fine. The duplicate-resource and copyright-header > issues stand.
Assignee | ||
Comment 6•11 years ago
|
||
Added license headers to all of the puppet files, and fixed the duplicate resource (turns out that was copy/paste fail).
Attachment #753534 -
Attachment is obsolete: true
Attachment #755906 -
Flags: review?(dustin)
Comment 7•11 years ago
|
||
Comment on attachment 755906 [details] [diff] [review] address comments Looks good, If you get info on the licensing of the web resources, please revisit :)
Attachment #755906 -
Flags: review?(dustin) → review+
Assignee | ||
Comment 8•11 years ago
|
||
Comment on attachment 755906 [details] [diff] [review] address comments (In reply to Dustin J. Mitchell [:dustin] from comment #7) > Comment on attachment 755906 [details] [diff] [review] > address comments > > Looks good, If you get info on the licensing of the web resources, please > revisit :) Thanks, will do.
Attachment #755906 -
Flags: checked-in+
Assignee | ||
Comment 9•11 years ago
|
||
Two things here: 1) stupid typo 2) publish bors status to a unique directory. I would've put public_html into dirs or something equivalent, but I don't think that's possible because it's created by a resource, not a class. I also had to use buildmaster::settings::master_root instead of master_basedir, because the latter only exists within the buildmaster module.
Attachment #755926 -
Flags: review?(dustin)
Comment 10•11 years ago
|
||
Comment on attachment 755926 [details] [diff] [review] fix bustage a=bustage anyway
Attachment #755926 -
Flags: review?(dustin) → review+
Assignee | ||
Comment 11•11 years ago
|
||
Comment on attachment 755926 [details] [diff] [review] fix bustage Landed to puppet320.
Attachment #755926 -
Flags: checked-in+
Assignee | ||
Comment 12•11 years ago
|
||
Works fine now.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
Updated•6 years ago
|
Component: General Automation → General
You need to log in
before you can comment on or make changes to this bug.
Description
•