-
Notifications
You must be signed in to change notification settings - Fork 18
Use branch of *target* instead of source build #783
Conversation
I tested with manual triggering of an update job that for RC builds (the only case where the repository/branch of the target and source builds differs), the ondemand_update jobs run correctly with the "mozilla-release" (target) instead of the "mozilla-beta" (source) branch name handed over. A failing job triggered before this change is http://mm-ci-production.qa.scl3.mozilla.com:8080/job/ondemand_update/26069/console A manual try with different branch is http://mm-ci-production.qa.scl3.mozilla.com:8080/job/ondemand_update/26070/console (and it's also green on treeherder) The config fed to trigger-ondemand that causes the failures is https://wiki.mozilla.org/QA/Desktop_Firefox/Releases/Configs/Fx46RC1 If I see things correctly, line 198 ends up assigning the *target* build's branch to testrun['branch'] so we can use that instead of build_details['branch'] which is derived from /entry/ which is the source build's version.
|
r? @mjzffr |
|
r? @sydvicious as well to make sure what I'm doing there looks like the right thing to do :) |
|
I am not overly familiar with the code in question. I believe that this will work with beta, but does nightly, aurora, release and esr still work? |
|
trigger-ondemand is only actually used for beta, release and ESR, nightly and aurora are triggered via pulse. |
|
so does it work for release and ESR? |
|
OK, the way I phrased it can be ambiguous potentially - beta, release and ESR are using trigger-ondemand with manually set config files, while nightly and aurora use pulse for triggering. For anything else than RCs (so for normal beta, release, or ESR builds), the branch values derived from source and target build versions are the same, that's why we didn't have errors so far - the beta channel runs for RC builds are a special case with those values differing, and this is the first time we run them with Marionette. |
|
So for anything else than RCs, it makes no difference from which one of /testrun/ or /build_details/ we take the branch. |
|
That said, I want to run a very small config file for each of a normal beta, a release, and the current RC on stage before we push this to production |
|
I poked around and as far as I can tell this change makes sense and won't break anything. Trepidatious r+ |
|
@KaiRo-at r+ |
|
Good catch @KaiRo-at, and thanks for the fix. I assume that everything got pushed to staging and production too. |
|
Yes, it did. On Tue, May 3, 2016 at 8:29 AM, Henrik Skupin notifications@github.com
|
I tested with manual triggering of an update job that for RC builds (the only case where the repository/branch of the target and source builds differs), the ondemand_update jobs run correctly with the "mozilla-release" (target) instead of the "mozilla-beta" (source) branch name handed over.
A failing job triggered before this change is http://mm-ci-production.qa.scl3.mozilla.com:8080/job/ondemand_update/26069/console
A manual try with different branch is http://mm-ci-production.qa.scl3.mozilla.com:8080/job/ondemand_update/26070/console (and it's also green on treeherder)
The config fed to trigger-ondemand that causes the failures is https://wiki.mozilla.org/QA/Desktop_Firefox/Releases/Configs/Fx46RC1
If I see things correctly, line 198 ends up assigning the target build's branch to testrun['branch'] so we can use that instead of build_details['branch'] which is derived from /entry/ which is the source build's version.