Closed
Bug 1275881
Opened 9 years ago
Closed 9 years ago
Add client and scopes for firefox-ui-tests triggered from mozmill-ci
Categories
(Taskcluster :: Services, defect)
Taskcluster
Services
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: whimboo, Assigned: dustin)
References
Details
I already had a conversation with Dustin and he initially did the following steps:
* The Client has been created as a temporary project with the name: project/qa/fx-ui-tests (https://tools.taskcluster.net/auth/clients/#project%252fqa%252ffx-ui-tests)
* The following scopes have been added:
** queue:route:tc-treeherder-stage.*
** queue:route:tc-treeherder.*
** docker-worker:cache:level-3-mozilla-central-test-workspace
** queue:create-task:aws-provisioner-v1/desktop-test
** queue:create-task:aws-provisioner-v1/qa-3-linux-fx-tests
** queue:define-task:aws-provisioner-v1/desktop-test
** queue:define-task:aws-provisioner-v1/qa-3-linux-fx-tests
qa-3-linux-fx-tests is the worker type for Linux as created on bug 1275681.
Today I tried to run a couple of tasks with desktop-test and then qa-3-linux-fx-tests, and noticed the following:
With the new worker type we always download the docker image. Is there something specific I would have to change to make sure caching is used? In that case its still the desktop-test image, and the following line is in my task definition:
"level-3-mozilla-central-test-workspace": "/home/worker/workspace"
The caching was working fine with desktop-test but with the new worker it always fails. Would I have to setup/define my own cache? Maybe the above is specific for desktop-test only.
I will do some more tests now for other branches and test flavors.
Flags: needinfo?(dustin)
Reporter | ||
Comment 1•9 years ago
|
||
I tried to run our tests for an Aurora nightly on mozilla-aurora but it fails with the following missing scopes:
* docker-worker:cache:level-3-mozilla-aurora-test-workspace
* queue:route:tc-treeherder-stage.mozilla-aurora.bbf243cfc912c8d00e5e78157564f7e44168fe48
For the first its still related to the above question, if I need it or not. But I wonder about the treeherder stage scope. There is `queue:route:tc-treeherder-stage.` set, so why does it not cover everything?
Assignee | ||
Comment 2•9 years ago
|
||
The images are cached on each instance, but you may have been using multiple images? Also, where are you pulling desktop-test from?
I changed the cache scope to docker-worker:cache:level-3-* so that should help.
The message said you *need* those two scopes, right? It didn't mention you already had one of them, perhaps?
Flags: needinfo?(dustin)
Reporter | ||
Comment 3•9 years ago
|
||
(In reply to Dustin J. Mitchell [:dustin] from comment #2)
> The images are cached on each instance, but you may have been using multiple
> images? Also, where are you pulling desktop-test from?
The task definition I was using is:
https://queue.taskcluster.net/v1/task/ZN1S19gcRwyKCRYZ3upzSQ
What do you mean with pulling desktop-test from? The docker image? Maybe that is the problem here.
> I changed the cache scope to docker-worker:cache:level-3-* so that should
> help.
>
> The message said you *need* those two scopes, right? It didn't mention you
> already had one of them, perhaps?
I tried to run a task for an Aurora nightly build which has a different scope. That's why this additional one is necessary. All in all we would need the scopes for all branches down to the esr ones. Looks like with your change that should have been done.
Assignee | ||
Comment 4•9 years ago
|
||
Yes, how are you generating
"image": {
"path": "public/image.tar",
"taskId": "YSckbw8PSK6wyTgDv6eeIA",
"type": "task-image"
},
as that taskId has a limited lifetime, and will change as the desktop-test docker image evolves..
Reporter | ||
Comment 5•9 years ago
|
||
(In reply to Dustin J. Mitchell [:dustin] from comment #4)
> "image": {
> "path": "public/image.tar",
> "taskId": "YSckbw8PSK6wyTgDv6eeIA",
> "type": "task-image"
> },
>
> as that taskId has a limited lifetime, and will change as the desktop-test
> docker image evolves..
That's an example as I used via the task creator. I actually never replaced that one! So I would have to fetch the last docker task via the index to figure out the appropriate taskid? When I do so I find the following:
https://tools.taskcluster.net/index/#docker.images.v1.mozilla-central.desktop-test/docker.images.v1.mozilla-central.desktop-test.latest
It tells me a taskid of `YSckbw8PSK6wyTgDv6eeIA` which is exactly what I have above.
Reporter | ||
Comment 6•9 years ago
|
||
Or do I always have to refer to inbound latest even when working on mozilla-aurora?
https://tools.taskcluster.net/index/#docker.images.v1.mozilla-inbound.desktop-test/docker.images.v1.mozilla-inbound.desktop-test.latest
Assignee | ||
Comment 7•9 years ago
|
||
You should probably refer to the latest from the branch you're testing.
Or maybe it's best to just build your own docker images for all of these, and put them on docker hub. I don't think it's worth building the infra to find in-tree docker images for tasks that are only temporarily out-of-tree.
For low volume, it's OK to pull docker images from docker hub. However, once this starts to scale up we'll need to move it in-tree and use the in-tree docker-image building system.
Reporter | ||
Comment 8•9 years ago
|
||
I talked with Dustin on IRC and we came to the conclusion that it will be better to build own docker images for firefox-ui-tests for the various Ubuntu versions we need. Those will be uploaded to docker hub, and the configs can be sticked into the tree. That means we can later easily reference those when the tests are getting triggered from in-tree graphs. I will file a new bug for that in a moment.
To check if all scopes are set I will try another task for mozilla-esr45 nightly builds. If that works well we can close this bug.
Assignee: nobody → dustin
Status: NEW → ASSIGNED
Reporter | ||
Comment 9•9 years ago
|
||
Dustin, I think all works fine. So we can close this bug. Thank you.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
Component: Platform and Services → Services
You need to log in
before you can comment on or make changes to this bug.
Description
•