Closed
Bug 476882
Opened 16 years ago
Closed 14 years ago
provide self-service forcing of builds at a specific changeset
Categories
(Release Engineering :: General, defect, P3)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: ted, Assigned: catlee)
References
Details
(Keywords: buildapi, Whiteboard: [automation][db][buildapi][self-serve])
Currently, one can use the buildbot waterfall to force a builder to build a specific changeset. This is useful when trying to track down sporadic test failures, as it's easier than backing out everything and starting over. However, this a) requires MPT VPN access, which not everyone has, and b) requires touching the buildbot waterfall, which is scary and also causes load issues on the master. Ideally we'd have an LDAP-authed webpage somewhere that would let developers easily force builds at specific revisions for testing. I hear the clobberer webapp is already LDAP authed, so perhaps this could live there?
Comment 1•16 years ago
|
||
I guess this could also be used for recreating specific older builds if needed after they'd been aged off ftp.m.o.
This feels different to the work-already-in-progress in other bugs to allow unittests, and talos, be run and re-run on specified pre-existing builds.
Component: Release Engineering → Release Engineering: Future
Comment 2•15 years ago
|
||
Mass move of bugs from Release Engineering:Future -> Release Engineering. See
http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.
Component: Release Engineering: Future → Release Engineering
Priority: -- → P3
Assignee | ||
Updated•14 years ago
|
Priority: P3 → P5
Whiteboard: [automation]
Assignee | ||
Updated•14 years ago
|
Whiteboard: [automation] → [automation][db]
Comment 3•14 years ago
|
||
Hm, does push-to-try cover this?
Comment 4•14 years ago
|
||
I think this bug is about self-service forcing for mozilla-central and other non-try branches for the purposes of, eg, finding the source of a test or build failure.
Comment 5•14 years ago
|
||
How does pushing that revision to try differ from that?
Reporter | ||
Comment 6•14 years ago
|
||
Because this gives us higher confidence that it's not a difference between the try server configuration vs. the production configuration. This would be useful for re-running unit/talos tests a few times on the same build to gain confidence that it's the build we want to tag for a beta, for example.
Updated•14 years ago
|
Assignee: nobody → jhford
Updated•14 years ago
|
Assignee: jhford → lsblakk
Status: NEW → ASSIGNED
Comment 7•14 years ago
|
||
Pushing the revision to try does mean you get the same configuration (same slave ref images, same test/talos suites), and with the try syntax now you could re-run a test/talos suite a few times if needed. Is there some other use case you're thinking of here or can we WONTFIX?
Assignee | ||
Comment 8•14 years ago
|
||
We want this for self-serve re-triggering of builds on other branches too. Like failed nightlies, etc.
Comment 9•14 years ago
|
||
Sounds like a job for the buildapi then. Attaching dependency on getting the ldap access to build.m.o/buildapi
Depends on: 591351
Updated•14 years ago
|
Whiteboard: [automation][db] → [automation][db][buildapi]
Assignee | ||
Updated•14 years ago
|
Assignee: lsblakk → catlee
Assignee | ||
Updated•14 years ago
|
Priority: P5 → P3
Assignee | ||
Comment 10•14 years ago
|
||
This can be done via the REST API, just need to hook up a simple web form to do this.
Whiteboard: [automation][db][buildapi] → [automation][db][buildapi][self-serve]
Assignee | ||
Comment 11•14 years ago
|
||
Now possible via the web interface.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•