Closed Bug 614629 Opened 14 years ago Closed 13 years ago

(tracker) Focus external interfaces at http://build.mozilla.org

Categories

(Release Engineering :: General, defect, P5)

defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 604688

People

(Reporter: dustin, Unassigned)

References

Details

(Keywords: buildapi, Whiteboard: [tracking bug][buildapi])

This URL currently only links to try server and some ancient release logs. This page should be a central point where others - inside and outside MoCo - can go to interface digitally with our group. That means: - links to all public interfaces, e.g., BuildAPI - any non-wiki-formatted interface documentation, e.g., pulse message formats We should look at http://pulse.mozilla.org as an example - it's purty, and has docs and contact emails. That's probably a nontrivial part of its adoption within the org. https://build.mozilla.org/logs/ should probably get deleted, too. Is there someone I could collaborate with to do some decent web UI design? My CSS is not so hot (as Buildbot proves).
Summary: Focus external interfaces at http://build.mozilla.org → (tracker) Focus external interfaces at http://build.mozilla.org
Depends on: 617129
(In reply to comment #0) > Is there someone I could collaborate with to do some decent web UI design? My > CSS is not so hot (as Buildbot proves). Do you have a particular look in mind? If not, if we like the simplicity of the pulse design, why not just ask Christian and copy his style sheets? Otherwise, you could try to cozy up to someone from webdev next week at the all-hands.
Coop: I actually like the look of https://build.mozilla.org/sendchange.cgi, so I'll just steal that. If it makes a webdev's eyes bleed, well, then that webdev can help me make it better :) Nick, when you get a chance, can you kill the remainder of /var/www/html/build/logs? I don't have permissions, even as a member of the 'build' group. Thanks!
OK, looking through the root of http://build.mozilla.org builds - nthomas's build status tool Do we want to keep this? Is this a supported tool for devs to use, or a one-off? clobberer - The Clobberer stage-clobberer Is stage-clobberer the staging version of this? Why "stage" and not "staging"? Can I rename it? logs needs to get deleted by nthomas and uid 515 patches patches-staging what are these? Can we kill 'em? sendchange.cgi staging/sendchange.cgi staging-lsblakk/sendchange.cgi uploadpatch.cgi will we ever re-enable this? If not, can we kill it? stackwalk I can't make this do anything from the various URLs I guessed. What is it? Does it work? This is bug 563678. This should probably be moved to an internal releng services system (cruncher?) talos It looks like this is just a dropzone for talos ZIPs and whatnot. Is this used by buildslaves? Is it used by developers? How should I document it on the front page? Should it be moved to an internal system (cruncher?)? update-bump-unit-tests It looks like this was just a one-off for some testing, since it hasn't been touched since early 2010. Can we kill it? Move it elsewhere?
(In reply to comment #3) > OK, looking through the root of http://build.mozilla.org > > > builds - nthomas's build status tool > > Do we want to keep this? Is this a supported tool for devs to use, or a > one-off? We publish our dumps of statusdb here too. Various folks are scraping these files, so if we move it, it needs planning. > clobberer - The Clobberer > stage-clobberer > > Is stage-clobberer the staging version of this? Why "stage" and not "staging"? > Can I rename it? Yes, need corresponding changes in staging_config.py I think. > patches > patches-staging > > what are these? Can we kill 'em? try server patches used to live here...I think they can go. > sendchange.cgi > staging/sendchange.cgi > staging-lsblakk/sendchange.cgi > uploadpatch.cgi > > will we ever re-enable this? If not, can we kill it? Even if we re-enable, they'll be different. I say kill em. > stackwalk > > I can't make this do anything from the various URLs I guessed. What is it? > Does it work? This is bug 563678. This should probably be moved to an > internal releng services system (cruncher?) Not currently used. We were about to turn it on, and then figured out how to make our symbols smaller so it became less urgent. I think some folks still want the functionality somewhere, but it is an internal releng service. > talos > > It looks like this is just a dropzone for talos ZIPs and whatnot. Is this used > by buildslaves? Is it used by developers? How should I document it on the > front page? Should it be moved to an internal system (cruncher?)? This is used by buildslaves for each talos run. Could also be moved to an internal system. So, it sounds like we need something else to host internal releng services, and I don't think cruncher is the right place. cruncher was never intended to be serving things in real-time.
(In reply to comment #4) > > talos > > > > It looks like this is just a dropzone for talos ZIPs and whatnot. Is this used > > by buildslaves? Is it used by developers? How should I document it on the > > front page? Should it be moved to an internal system (cruncher?)? > > This is used by buildslaves for each talos run. Could also be moved to an > internal system. > > So, it sounds like we need something else to host internal releng services, and > I don't think cruncher is the right place. cruncher was never intended to be > serving things in real-time. Did we put the talos bundles on build.m.o so it could be reachable by a-tools at all? or the public? jhammel, anodelman?
We put them on build.m.o so we didn't have to use hg and/or FileDownload to get required files onto the test machines on every test run.
Blocks: 617129
No longer depends on: 617129
My suggestions: - move clobberer to http://clobberer.build.mozilla.org/ - put BuildAPI at http://api.build.mozilla.org/ - link both of these from http://build.mozilla.org - add TryChooser hosted directly at http://build.mozilla.org/trychooser - add anamarias reports to the site, too? - only require LDAP auth where necessary, e.g., clobberer but not TryChooser If using *.build.mozilla.org is too hard because of the network partitions, we could either clutter the top-level namespace (mozilla.org) or add a new, "public" subdomain, releng.mozilla.org. - create a new internal web services host (bug 618109) - move talos bundles there (judging from comment #4 and comment #6) - host slave allocator there
(In reply to comment #3) > logs > needs to get deleted by nthomas and uid 515 I got the files I could. Easiest to ask IT to get the rest as 515 seems to be gone.
Assignee: dustin → nobody
Depends on: 629477
Priority: -- → P3
Whiteboard: [tracking bug][buildapi]
No longer blocks: 617129
Depends on: 617129
Priority: P3 → P5
Please don't make any more public urls on build.m.o until it's renamed. See bug 604688.
I think this can be closed in favor of bug 604688. Concur?
the only remaining depend bug on this one is 629477 and 604688 lists it as a blocker so I'm leaning towards +1 to dup'ing forward
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Keywords: buildapi
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.