606322 - Create buildduty helpers for triggering builds/talos/tests on any branch

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[Lukas Blakk [:lsblakk] use ?needinfo]

Example is getting a bug like bug 606053 where you have 3 changesets * platforms * talos suites and that's a lot to go chasing around. In that particular case I chose to build sendchanges from following the Master link in the scheduler db for each platform, to get to the packageURL but to automate this we could use a script that can grab that link and troll it for the fileURL and packageURL (for unittests) and then build a sendchange out of that information.

Comment 1

[Armen [:armenzg]]

The problem is determining what is the buildid for each platform because the revision the developer already gives it to us.

If we could have symlinks from changeset to the ftp location that would be great. Like tinderbox-builds/changesets/$changeset to the right tinderbox-builds/$branch-$platform/$buildid this problem could make this problem solvable.

Anways, what I want to say that we need to match a changeset/branch to an FTP location for every platform. The two ideas are the symlinking or pulling the ftp location out of the properties and/ord DBs we have.

Comment 2

[Nick Thomas [:nthomas] (UTC+12)]

Lets not call the epoch timestamps at tinderbox-builds/$branch-$platform buildid's, since buildid means YYYYMMDDHHSS. Other than that you're basically describing bug 584178.

Comment 3

[Lukas Blakk [:lsblakk] use ?needinfo]

The great thing about this idea is that it uses schedulerdb to find the link to the page for that build on it's master, and you can grab fileURL and packageURL there so you don't even need to know the dir structure at all to be able to create a sendchange this way. You can just test that the links resolve (to be sure they are still up). We don't need buildid or epoch timestamps.

Comment 4

[Lukas Blakk [:lsblakk] use ?needinfo]

and in case i wasn't clear enough - all you would need to run this helper script is the changeset, and then some flags for what platforms, talos, unittest you want to re-build/re-run

Comment 5

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: adds a rebuild button to running/revision templates

tested on a local button while connected to build-vpn with a staging-master url successfully.

Comment 6

[Lukas Blakk [:lsblakk] use ?needinfo]

<table>
<td><form method="post" action="http://staging-master.build.mozilla.org:8010/builders/Linux%20mozilla-central%20build/builds/244/rebuild" class="command rebuild"><input type="submit" value="rebuild"></form></td>
</table>

is what I tested.

Comment 7

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 486857 [details] [diff] [review]
adds a rebuild button to running/revision templates

http://hg.mozilla.org/build/buildapi/rev/44ea7d036c4a

Comment 8

[Lukas Blakk [:lsblakk] use ?needinfo]

checked in a bustage fix for key errors on 'url':
http://hg.mozilla.org/build/buildapi/rev/71000b93d929

Comment 9

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: remove rebuild button from running template since it is public facing

turns out you can see this on the mirrored http://build.mozilla.org/builds/running.html page so instead of frustrating developers with this mirage...i took it out.

Comment 10

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 487992 [details] [diff] [review]
remove rebuild button from running template since it is public facing

http://hg.mozilla.org/build/buildapi/rev/fea5be7ad234