Closed
Bug 1197204
Opened 9 years ago
Closed 8 years ago
buildbot bridge should support changes
Categories
(Release Engineering :: General, defect)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: armenzg, Unassigned)
Details
Changes [1][2] included as part of the SourceStamp is what allows test jobs to work. In bug 1194264#c12 [3] I show that the buildprops.json which the test slave receives is incomplete and we can't receive the installer url and the test url. I'm happy to submit tasks to help test this. [1] https://github.com/mozilla/buildbot-bridge/blob/master/bbb/servicebase.py#L232 [2] http://mxr.mozilla.org/build/source/buildbot/master/buildbot/sourcestamp.py#51 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1194264#c12
Reporter | ||
Comment 1•9 years ago
|
||
The comments on the try emails is useful since it becomes the subject line. This is specially when several patches are pushed and you forget to open the links to treeherder from the console after you push. You could, however, open https://treeherder.mozilla.org/#/jobs?repo=try&author=armenzg@mozilla.com However, we could grab this info from pushlog directly if we would need to. In other words, it is not essential but it is nice. On 2015-08-20 6:13 PM, Ben Hearsum wrote: > They do not. I suspect that try jobs were never something that I tested when originally validating the bridge. So, https://bugzilla.mozilla.org/show_bug.cgi?id=1195751 is already talking about adding "product" and "who" to what the bridge injects into the database, it's probably not much work to create a Change too. Though I might take a brief look and see if try_mailer.py _really_ needs the Change. > > On Fri, Aug 21, 2015 at 09:54:44AM +1200, Nick Thomas wrote: >> Here's another error we hit: >> >> Running [u'/builds/buildbot/try1/bin/python', >> u'/builds/buildbot/try1/lib/python2.7/site-packages/buildbotcustom/bin/try_mailer.py', >> u'--log-url', u' >> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/armenzg@mozilla.com-da280e3f1ab3/try-android-api-9/try-android-api-9-bm78-try1-build1125.txt.gz', >> u'-f', u'tryserver@build.mozilla.org', u'--to-author', >> u'/builds/buildbot/try1/master/try-android-api-9', u'1125'] >> >> Traceback (most recent call last): >> File >> "/builds/buildbot/try1/lib/python2.7/site-packages/buildbotcustom/bin/try_mailer.py", >> line 201, in <module> >> match = re.search("try: ", build.source.changes[-1].comments) >> IndexError: tuple index out of range >> >> Do these builds have a buildbot change associated with them ?
Comment 3•9 years ago
|
||
I just started looking at this some more and I realized that most of the information that the Change wants isn't available through the Taskcluster API. Eg: author and comments (aka commit message) aren't part of Tasks. We might be able to look them up through hg.mozilla.org, but not all Tasks would necessarily have an associated hg.mozilla.org revision. Jonas, is there any way to get this information through Taskcluster? It seems like the decision task would have access to it, but it doesn't get forwarded along.
Flags: needinfo?(jopsen)
Comment 4•9 years ago
|
||
> Jonas, is there any way to get this information through Taskcluster?
> It seems like the decision task would have access to it, but it doesn't get forwarded along.
Well, we probably have to patch the decision task to forward the information you want.
wcosta is working on redesigning decision task logic. But I suspect that in the current state we
already have some variables you can add to tasks.
Is this information that bb-bridge should forward/inject into buildbot?
If so it should be part of task.payload, and decision task should insert it when the task is created.
---
I'm not sure what information you're talking about. But note that task definitions are not designed
to carry large data sets or unbounded lists it's a bad idea to do so because corner cases could break.
Flags: needinfo?(jopsen)
Comment 5•9 years ago
|
||
(In reply to Jonas Finnemann Jensen (:jonasfj) from comment #4) > > Jonas, is there any way to get this information through Taskcluster? > > It seems like the decision task would have access to it, but it doesn't get forwarded along. > > Well, we probably have to patch the decision task to forward the information > you want. > wcosta is working on redesigning decision task logic. But I suspect that in > the current state we > already have some variables you can add to tasks. > > Is this information that bb-bridge should forward/inject into buildbot? > If so it should be part of task.payload, and decision task should insert it > when the task is created. > > --- > I'm not sure what information you're talking about. But note that task > definitions are not designed > to carry large data sets or unbounded lists it's a bad idea to do so because > corner cases could break. In my opinion, it is. We're talking about commit metadata - notably the Author, commit message, and the files changed. So...it depends on what you mean by unbounded :). The file lists can get quite long for merges.
Comment 6•9 years ago
|
||
That why I said unbounded: "commit message" singular is probably fine, but "commit messages" plural is probably bad :) Same with list of files, that shouldn't be in the task definition. Even if it can be in most cases, the corner cases that don't work will be a major pain to find, debug and work around.
Comment 7•9 years ago
|
||
I don't know what input BB needs or how it's suppose to get there. But perhaps the gecko-decision tasks creates an artifact with this info, and provide bb-bridge with a link to it.
Comment 8•9 years ago
|
||
(In reply to Jonas Finnemann Jensen (:jonasfj) from comment #7) > I don't know what input BB needs or how it's suppose to get there. Buildbot generally creates "Change" objects that represent changes made in a VCS. They contain some of the commit metadata (author, commit message, files being the parts we care about). There's also SourceStamps, which are a collection of Changes, and end up being referenced by BuildRequests (the thing we are translated Tasks to). In the Buildbot model, Changes are created by in-process objects that poll for or listen for notification of commits. Eg: we have a poller that watches hg.mozilla.org for new pushes, and creates Changes when found. It's not quite clear to me what the Taskcluster equivalent to this is (or if it could even perform a similar function). > But perhaps the gecko-decision tasks creates an artifact with this info, and > provide bb-bridge with a link to it. This seems like a pretty reasonable idea.
Reporter | ||
Comment 9•9 years ago
|
||
The information about which files where touched by this push will be relevant to the decision task once buildbot jobs migrate to TC. Right now, in the buildbot world when a push only touches Firefox for mobile files it will *only* trigger mobile jobs. When the buildbot jobs come to TC, we will need to analyze the files which a push touches and determine which platforms needs to be scheduled. The ones that don't need to be scheduled would have the self-dependency to prevent them from running. ################ With regards to my needs, test jobs in the buildbot world need a fake Buildbot Changes. The fake Changes pretends to say that the push has touched two files. The files are the installer URL and the tests package json. Mozharness can then grab the two files from the "Changes". This fake Changes is triggered via the "buildbot sendchange installer_url test_package_json" command in the builds side. For mozci, when we schedule task graph where there is a build and a dependent job, we need to either have the same transport mechanism (the Changes of the test job contains those two files) or another one. The current model where mozharness grabs the info through the fake Changes is not something we want to repeat when we migrate to TC. We want to make mozharness less aware of the CI it is running within. I can see that current TC dependent tasks have the --installer-url and --test-packages-url explicitely pass [1] For the BBB tasks, we won't be able to switch from --read-buildbot-configs to explicit urls being passed. However, when we have a build triggered in TC and the tests run on buildbot, we will have to make sure that the BBB will set the fake Changes for those tests. Perhaps, we need to add sendchange steps to those TC builds OR teach the BBB listener to set the fake Changes by determining where the TC build uploaded files to (I know this is possible). [1] python ./mozharness/scripts/gaia_build_unit.py --no-read-buildbot-config --config-file ./mozharness/configs/b2g/gaia_integration_config.py --config-file ./mozharness_configs/gaia_integration_override.py --config-file ./mozharness_configs/remove_executables.py --no-pull --download-symbols ondemand --installer-url https://queue.taskcluster.net/v1/task/8QIxbj4CRQCf77KcFBUflA/artifacts/public/build/target.linux-x86_64.tar.bz2 --test-packages-url https://queue.taskcluster.net/v1/task/8QIxbj4CRQCf77KcFBUflA/artifacts/public/build/test_packages.json --gaia-repo https://hg.mozilla.org/integration/gaia-central --gaia-dir /home/worker
Comment 10•9 years ago
|
||
(In reply to Armen Zambrano Gasparnian [:armenzg] from comment #9) > The information about which files where touched by this push will be > relevant to the decision task once buildbot jobs migrate to TC. > > Right now, in the buildbot world when a push only touches Firefox for mobile > files it will *only* trigger mobile jobs. > > When the buildbot jobs come to TC, we will need to analyze the files which a > push touches and determine which platforms needs to be scheduled. The ones > that don't need to be scheduled would have the self-dependency to prevent > them from running. > > ################ > > With regards to my needs, test jobs in the buildbot world need a fake > Buildbot Changes. The fake Changes pretends to say that the push has touched > two files. The files are the installer URL and the tests package json. > Mozharness can then grab the two files from the "Changes". > This fake Changes is triggered via the "buildbot sendchange installer_url > test_package_json" command in the builds side. > > For mozci, when we schedule task graph where there is a build and a > dependent job, we need to either have the same transport mechanism (the > Changes of the test job contains those two files) or another one. > > The current model where mozharness grabs the info through the fake Changes > is not something we want to repeat when we migrate to TC. We want to make > mozharness less aware of the CI it is running within. > > I can see that current TC dependent tasks have the --installer-url and > --test-packages-url explicitely pass [1] > > For the BBB tasks, we won't be able to switch from --read-buildbot-configs > to explicit urls being passed. > However, when we have a build triggered in TC and the tests run on buildbot, > we will have to make sure that the BBB will set the fake Changes for those > tests. Perhaps, we need to add sendchange steps to those TC builds OR teach > the BBB listener to set the fake Changes by determining where the TC build > uploaded files to (I know this is possible). > > [1] > python ./mozharness/scripts/gaia_build_unit.py --no-read-buildbot-config > --config-file ./mozharness/configs/b2g/gaia_integration_config.py > --config-file ./mozharness_configs/gaia_integration_override.py > --config-file ./mozharness_configs/remove_executables.py --no-pull > --download-symbols ondemand --installer-url > https://queue.taskcluster.net/v1/task/8QIxbj4CRQCf77KcFBUflA/artifacts/ > public/build/target.linux-x86_64.tar.bz2 --test-packages-url > https://queue.taskcluster.net/v1/task/8QIxbj4CRQCf77KcFBUflA/artifacts/ > public/build/test_packages.json --gaia-repo > https://hg.mozilla.org/integration/gaia-central --gaia-dir /home/worker You make some good points here, but keep in mind that the Bridge _cannot_ directly influence Buildbot command lines. We can pass information in the SourceStamp, Changes, BuildRequest, and Properties -- but the command line is not something associated with any of these, and cannot be modified by the Bridge. One trick we're looking at using elsewhere is to pass the things we need as properties and have the script read them rather than command line arguments. But I think the simpler thing to do here is put them in the Change. Your comment also made me realize that passing VCS metadata to the Bridge won't help your use case of needing the filenames of the build artifacts, so that would require the decision task to do something different. I'd really like to move forward here, so here's what I suggest: * I'll add support in the Bridge for finding Change information in Task payloads. * Someone else needs to figure out how to get the "taskcluster-graph" command to add the necessary filenames to the necessary Tasks. It looks to me like some of this information may be available in https://dxr.mozilla.org/mozilla-central/source/testing/taskcluster/mach_commands.py?offset=100#258, based on some of the keys in "params".
Reporter | ||
Comment 11•9 years ago
|
||
(In reply to Ben Hearsum (:bhearsum) from comment #10) > (In reply to Armen Zambrano Gasparnian [:armenzg] from comment #9) > > You make some good points here, but keep in mind that the Bridge _cannot_ > directly influence Buildbot command lines. We can pass information in the > SourceStamp, Changes, BuildRequest, and Properties -- but the command line > is not something associated with any of these, and cannot be modified by the > Bridge. One trick we're looking at using elsewhere is to pass the things we > need as properties and have the script read them rather than command line > arguments. But I think the simpler thing to do here is put them in the > Change. > Yes, we're in the same page here. I probably did not explain it clearly. > Your comment also made me realize that passing VCS metadata to the Bridge > won't help your use case of needing the filenames of the build artifacts, so > that would require the decision task to do something different. > I believe it would work. Doesn't the BBB listen to the sendchange that the build it triggered? That is what sets the Change for test jobs in our normal buildbot flow. > I'd really like to move forward here, so here's what I suggest: > * I'll add support in the Bridge for finding Change information in Task > payloads. Please let me know once you have this running on Alder so I can test it. > * Someone else needs to figure out how to get the "taskcluster-graph" > command to add the necessary filenames to the necessary Tasks. It looks to > me like some of this information may be available in > https://dxr.mozilla.org/mozilla-central/source/testing/taskcluster/ > mach_commands.py?offset=100#258, based on some of the keys in "params". By filenames, do you mean the files that the push is touching? Would the "files" value in here be what you mean? https://hg.mozilla.org/projects/alder/json-pushes?changeset=e7f0847b2670&full=1 I assume that adding such filenemas would *only* apply for tasks which use the buildbot-bridge.
Comment 12•9 years ago
|
||
(In reply to Armen Zambrano Gasparnian [:armenzg] from comment #11) > (In reply to Ben Hearsum (:bhearsum) from comment #10) > > (In reply to Armen Zambrano Gasparnian [:armenzg] from comment #9) > > > > You make some good points here, but keep in mind that the Bridge _cannot_ > > directly influence Buildbot command lines. We can pass information in the > > SourceStamp, Changes, BuildRequest, and Properties -- but the command line > > is not something associated with any of these, and cannot be modified by the > > Bridge. One trick we're looking at using elsewhere is to pass the things we > > need as properties and have the script read them rather than command line > > arguments. But I think the simpler thing to do here is put them in the > > Change. > > > Yes, we're in the same page here. I probably did not explain it clearly. Okay, great! > > Your comment also made me realize that passing VCS metadata to the Bridge > > won't help your use case of needing the filenames of the build artifacts, so > > that would require the decision task to do something different. > > > I believe it would work. Doesn't the BBB listen to the sendchange that the > build it triggered? > That is what sets the Change for test jobs in our normal buildbot flow. The Bridge doesn't pay attention to sendchanges at all; the only time it creates BuildRequests is in responding to task-pending events from Taskcluster. So the trick here is that the taskcluster-graph command needs to know the filenames of the build and test packages that the test jobs will need. I'm not sure how to figure that out =\. > > I'd really like to move forward here, so here's what I suggest: > > * I'll add support in the Bridge for finding Change information in Task > > payloads. > > Please let me know once you have this running on Alder so I can test it. Will do. > > * Someone else needs to figure out how to get the "taskcluster-graph" > > command to add the necessary filenames to the necessary Tasks. It looks to > > me like some of this information may be available in > > https://dxr.mozilla.org/mozilla-central/source/testing/taskcluster/ > > mach_commands.py?offset=100#258, based on some of the keys in "params". > > By filenames, do you mean the files that the push is touching? > Would the "files" value in here be what you mean? > https://hg.mozilla.org/projects/alder/json- > pushes?changeset=e7f0847b2670&full=1 This is correct for Build jobs. For test jobs, see above about the taskcluster-graph command. > I assume that adding such filenemas would *only* apply for tasks which use > the buildbot-bridge. Right, it would be something that's specific to buildbot-bridge Task payloads, just like sourcestamp and buildername are.
Reporter | ||
Comment 13•9 years ago
|
||
(In reply to Ben Hearsum (:bhearsum) from comment #12) > (In reply to Armen Zambrano Gasparnian [:armenzg] from comment #11) > > (In reply to Ben Hearsum (:bhearsum) from comment #10) ... > > > Your comment also made me realize that passing VCS metadata to the Bridge > > > won't help your use case of needing the filenames of the build artifacts, so > > > that would require the decision task to do something different. > > > > > I believe it would work. Doesn't the BBB listen to the sendchange that the > > build it triggered? > > That is what sets the Change for test jobs in our normal buildbot flow. > > The Bridge doesn't pay attention to sendchanges at all; the only time it > creates BuildRequests is in responding to task-pending events from > Taskcluster. So the trick here is that the taskcluster-graph command needs > to know the filenames of the build and test packages that the test jobs will > need. I'm not sure how to figure that out =\. > If there is a way to know exactly where the build will put the files and the file names we could put it in the test's task definition. Otherwise, we would need to teach mozharness to query the build's task and enquiry about the artifacts it uploaded. If the latter, we would not need this bug but have to file a mozharness bug.
Comment 14•9 years ago
|
||
(In reply to Armen Zambrano Gasparnian [:armenzg] from comment #13) > (In reply to Ben Hearsum (:bhearsum) from comment #12) > > (In reply to Armen Zambrano Gasparnian [:armenzg] from comment #11) > > > (In reply to Ben Hearsum (:bhearsum) from comment #10) > ... > > > > Your comment also made me realize that passing VCS metadata to the Bridge > > > > won't help your use case of needing the filenames of the build artifacts, so > > > > that would require the decision task to do something different. > > > > > > > I believe it would work. Doesn't the BBB listen to the sendchange that the > > > build it triggered? > > > That is what sets the Change for test jobs in our normal buildbot flow. > > > > The Bridge doesn't pay attention to sendchanges at all; the only time it > > creates BuildRequests is in responding to task-pending events from > > Taskcluster. So the trick here is that the taskcluster-graph command needs > > to know the filenames of the build and test packages that the test jobs will > > need. I'm not sure how to figure that out =\. > > > If there is a way to know exactly where the build will put the files and the > file names we could put it in the test's task definition. I don't think it's possible to predict where Buildbot Builds will upload. > Otherwise, we would need to teach mozharness to query the build's task and > enquiry about the artifacts it uploaded. An alternative is to change the builds to have predictable filenames for the artifacts they upload to Taskcluster. Maybe that's harder though... > If the latter, we would not need this bug but have to file a mozharness bug. Perhaps. It's still very murky to me...but if you're confident that this is the case, I trust you :). Let me know what you want to do. I think we might want this feature in the Bridge at some point even if your specific use case doesn't require it.
Reporter | ||
Comment 15•9 years ago
|
||
(In reply to Ben Hearsum (:bhearsum) from comment #14) > (In reply to Armen Zambrano Gasparnian [:armenzg] from comment #13) > > (In reply to Ben Hearsum (:bhearsum) from comment #12) > > > (In reply to Armen Zambrano Gasparnian [:armenzg] from comment #11) > > > > (In reply to Ben Hearsum (:bhearsum) from comment #10) > > ... > > > > > Your comment also made me realize that passing VCS metadata to the Bridge > > > > > won't help your use case of needing the filenames of the build artifacts, so > > > > > that would require the decision task to do something different. > > > > > > > > > I believe it would work. Doesn't the BBB listen to the sendchange that the > > > > build it triggered? > > > > That is what sets the Change for test jobs in our normal buildbot flow. > > > > > > The Bridge doesn't pay attention to sendchanges at all; the only time it > > > creates BuildRequests is in responding to task-pending events from > > > Taskcluster. So the trick here is that the taskcluster-graph command needs > > > to know the filenames of the build and test packages that the test jobs will > > > need. I'm not sure how to figure that out =\. > > > > > If there is a way to know exactly where the build will put the files and the > > file names we could put it in the test's task definition. > > I don't think it's possible to predict where Buildbot Builds will upload. > For some reason my mind was thinking of a TC task where artifacts might be predictable. > > Otherwise, we would need to teach mozharness to query the build's task and > > enquiry about the artifacts it uploaded. > > An alternative is to change the builds to have predictable filenames for the > artifacts they upload to Taskcluster. Maybe that's harder though... > Do buildbot jobs upload through TaskCluster? Can we query which files a buildbot job uploaded? If not, can we upload some meta data about uploaded builds somewhere? Similar to how blobber uploads a summary of uploaded artifacts. > > If the latter, we would not need this bug but have to file a mozharness bug. > > Perhaps. It's still very murky to me...but if you're confident that this is > the case, I trust you :). Let me know what you want to do. > Only if I have a way to query about uploaded builds/tests for a buildbot job. > I think we might want this feature in the Bridge at some point even if your > specific use case doesn't require it. Yes, I agree.
Comment 16•9 years ago
|
||
(In reply to Armen Zambrano Gasparnian [:armenzg] from comment #15) > (In reply to Ben Hearsum (:bhearsum) from comment #14) > > (In reply to Armen Zambrano Gasparnian [:armenzg] from comment #13) > > > (In reply to Ben Hearsum (:bhearsum) from comment #12) > > > > (In reply to Armen Zambrano Gasparnian [:armenzg] from comment #11) > > > > > (In reply to Ben Hearsum (:bhearsum) from comment #10) > > > ... > > > > > > Your comment also made me realize that passing VCS metadata to the Bridge > > > > > > won't help your use case of needing the filenames of the build artifacts, so > > > > > > that would require the decision task to do something different. > > > > > > > > > > > I believe it would work. Doesn't the BBB listen to the sendchange that the > > > > > build it triggered? > > > > > That is what sets the Change for test jobs in our normal buildbot flow. > > > > > > > > The Bridge doesn't pay attention to sendchanges at all; the only time it > > > > creates BuildRequests is in responding to task-pending events from > > > > Taskcluster. So the trick here is that the taskcluster-graph command needs > > > > to know the filenames of the build and test packages that the test jobs will > > > > need. I'm not sure how to figure that out =\. > > > > > > > If there is a way to know exactly where the build will put the files and the > > > file names we could put it in the test's task definition. > > > > I don't think it's possible to predict where Buildbot Builds will upload. > > > For some reason my mind was thinking of a TC task where artifacts might be > predictable. That might be try for Taskcluster implemented Tasks (or might not be), but it's definitely not true for Buildbot implemented Tasks, eg: https://tools.taskcluster.net/index/artifacts/#buildbot.revisions.047240fb3b4c21d68d02de0737bc6a8c9b130b14.fx-team/buildbot.revisions.047240fb3b4c21d68d02de0737bc6a8c9b130b14.fx-team.win32 > > > Otherwise, we would need to teach mozharness to query the build's task and > > > enquiry about the artifacts it uploaded. > > > > An alternative is to change the builds to have predictable filenames for the > > artifacts they upload to Taskcluster. Maybe that's harder though... > > > Do buildbot jobs upload through TaskCluster? > Can we query which files a buildbot job uploaded? Yes, they do. There's some special logic in Mozharness that uploads artifacts even for Builds that aren't scheduled by Taskcluster. The link above is an example of that. > If not, can we upload some meta data about uploaded builds somewhere? > Similar to how blobber uploads a summary of uploaded artifacts. Perhaps. I think we're already doing this for test packages, eg: https://queue.taskcluster.net/v1/task/r13ucifnThKvuVVlevTXTw/artifacts/public/build/test_packages.json. > > > If the latter, we would not need this bug but have to file a mozharness bug. > > > > Perhaps. It's still very murky to me...but if you're confident that this is > > the case, I trust you :). Let me know what you want to do. > > > Only if I have a way to query about uploaded builds/tests for a buildbot job. How are you feeling about being able to progress now? If it's still not clear how to proceed, we should talk soon. Things are awfully confused in my head right now.
Reporter | ||
Comment 17•9 years ago
|
||
There are two parts were changes are involved in the buildbot side. 1 - hg push -> BB scheduler -> creates Changes with files touched 2 - buildbot sendchange -> BB scheduler -> creates Changes with files indicated by sendchange I only care about the 2nd part. If the BBB does not listen to buildbot sendchanges then we have these options: 1 - have a defined upload path which can be used when creating test tasks 2 - have a way to query about uploaded artifacts by parent task I will see if I can query about uploaded artifacts through the index. Is this a bit more clear?
Comment 18•9 years ago
|
||
(In reply to Armen Zambrano Gasparnian [:armenzg] from comment #17) > There are two parts were changes are involved in the buildbot side. > > 1 - hg push -> BB scheduler -> creates Changes with files touched > > 2 - buildbot sendchange -> BB scheduler -> creates Changes with files > indicated by sendchange > > I only care about the 2nd part. > > If the BBB does not listen to buildbot sendchanges then we have these > options: I'm pretty sure you already know this to be true, but to be clear: The Buildbot Bridge knows absolutely nothing about Sendchanges, HgPollers, or anything of that sort. The _only_ things in Buildbot that it responds to are Build Start and Build Finish. > 1 - have a defined upload path which can be used when creating test tasks > 2 - have a way to query about uploaded artifacts by parent task > > I will see if I can query about uploaded artifacts through the index. Sounds good to me.
Reporter | ||
Comment 19•9 years ago
|
||
When a build task finishes, could we create the associated test jobs with a Change with the package and test urls set as the files?
We can grab this info from the taskcluster queue.
> for artifact in queue.listLatestArtifacts('r13ucifnThKvuVVlevTXTw')['artifacts']:
> name = os.path.basename(artifact['name'])
> if name.startswith('firefox') and name.endswith('win32.zip'):
> print name
> if name.endswith('test_packages.json'):
> print name
> ....:
> firefox-43.0a1.en-US.win32.zip
> test_packages.json
If this was added by the BBB when scheduling new test jobs, there would not be anymore changes needed by me since this information would end up in the buildprops.json of the test job which Mozharness would then use through the read-buildbot-config method.
I can also move this discovery part to mozharness.
The code above still need some love:
* determine the runId instead of grabbing info from the latest run of a task
* determine the URLs for those two artifacts (there is queue.getArtifact() but it is the actual file rather than a URL)
Reporter | ||
Comment 20•9 years ago
|
||
I'm not going to block on this since it is not clear that having Changes would help me (unless we could have the same hack for test jobs). I'm going to work on bug 1203085 to make test jobs discover the installer and test urls.
No longer blocks: 1194264
Updated•9 years ago
|
Assignee: bhearsum → nobody
Comment 21•9 years ago
|
||
bug 1205931 has found a more urgent need for the bridge to support Changes (which is referenced earlier in this bug, but got lost in the talk about files): try_mailer.py, which runs for every try push, requires a Change with at least a comment attached to it.
Comment 22•8 years ago
|
||
(In reply to Ben Hearsum (:bhearsum) from comment #21) > bug 1205931 has found a more urgent need for the bridge to support Changes > (which is referenced earlier in this bug, but got lost in the talk about > files): try_mailer.py, which runs for every try push, requires a Change with > at least a comment attached to it. Ben: did this get fixed as part of bug 1205931, or is there still work to do here?
Flags: needinfo?(bhearsum)
Comment 23•8 years ago
|
||
(In reply to Chris Cooper [:coop] from comment #22) > (In reply to Ben Hearsum (:bhearsum) from comment #21) > > bug 1205931 has found a more urgent need for the bridge to support Changes > > (which is referenced earlier in this bug, but got lost in the talk about > > files): try_mailer.py, which runs for every try push, requires a Change with > > at least a comment attached to it. > > Ben: did this get fixed as part of bug 1205931, or is there still work to do > here? Doesn't look like it. I'm not sure if we still need this bug for other reasons, though. Armen?
Flags: needinfo?(bhearsum) → needinfo?(armenzg)
Reporter | ||
Comment 24•8 years ago
|
||
I believe I worked around this. If you want to know how or where, please let me know and I will do bugzilla/GitHub archaeolgy.
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(armenzg)
Resolution: --- → WORKSFORME
Assignee | ||
Updated•6 years ago
|
Component: General Automation → General
You need to log in
before you can comment on or make changes to this bug.
Description
•