provide self-service forcing of builds at a specific changeset

RESOLVED FIXED

Status

Release Engineering
General
P3
normal
RESOLVED FIXED
9 years ago
4 years ago

People

(Reporter: ted, Assigned: catlee)

Tracking

({buildapi})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [automation][db][buildapi][self-serve])

(Reporter)

Description

9 years ago
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?
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

8 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

8 years ago
Priority: P3 → P5
Whiteboard: [automation]
(Assignee)

Updated

8 years ago
Whiteboard: [automation] → [automation][db]
Hm, does push-to-try cover this?
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.
How does pushing that revision to try differ from that?
(Reporter)

Comment 6

7 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.
Assignee: nobody → jhford
Assignee: jhford → lsblakk
Status: NEW → ASSIGNED
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

7 years ago
We want this for self-serve re-triggering of builds on other branches too.  Like failed nightlies, etc.
Sounds like a job for the buildapi then. Attaching dependency on getting the ldap access to build.m.o/buildapi
Depends on: 591351
Whiteboard: [automation][db] → [automation][db][buildapi]
(Assignee)

Updated

7 years ago
Assignee: lsblakk → catlee
(Assignee)

Updated

7 years ago
Priority: P5 → P3
(Assignee)

Updated

7 years ago
Depends on: 608052
(Assignee)

Comment 10

7 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

7 years ago
Now possible via the web interface.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED

Updated

5 years ago
Keywords: buildapi
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.