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.
Mass move of bugs from Release Engineering:Future -> Release Engineering. See http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.
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?
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.
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?
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
This can be done via the REST API, just need to hook up a simple web form to do this.
Now possible via the web interface.