mozilla :: #taskcluster

11 Jul 2017
07:01pmooredustin: isn't that an error coming from json-e rather than from travis?
07:07aselagea|builddutymorning
07:07aselagea|builddutyany chance someone could take a look at https://bugzilla.mozilla.org/show_bug.cgi?id=1379886#c1?
07:07firebotBug 1379886 NEW, nobody@mozilla.org Seamonkey Checkin causing Build Failures on Release
07:08aselagea|builddutythe decision task is failing due to missing scopes
09:43Tomcat|sheriffdutywcosta, filing a bug
09:43wcostaTomcat|sheriffduty: that was fast
09:43Tomcat|sheriffduty:)
09:44Tomcat|sheriffdutyfor you anytime ;-)
12:14Callekgrenade: so, fyi, there may be some conflicts between your code for win talos and the "tier 1 windows stuff" (with BBB), if thats the case I may be poking you to help resolve those conflicts, fwiw
12:15Callek(since we need to trigger all testing from TC, we'd be scheduling talos and some stuff via BBB)
12:15grenadeof course
12:31jhfordTomcat|sheriffduty: hi, are there any releases/merges/uplifts happening today?
12:32jhfordrelated, if i can get this patch deployed today, the provisioner ui should have more information back in it very soon
12:33Tomcat|sheriffdutyjhford: hm uplift happen like checkins but merges are done during my shift and no release today i think
12:33jhfordahh, k. to rephrase the question slightly: OK for me to deploy some changes?
13:05jhfordTomcat|sheriffduty: ^
13:05Tomcat|sheriffdutyjhford: yeah i think so :)
13:06Tomcat|sheriffdutyif its a big change it might be worth to inform the sheriffs list
13:06Tomcat|sheriffdutyso that KWierso|afk etc is aware when he wakes up
13:10jhfordit's not a big change
13:10jhfordjust a couple small tweaks to the EC2-Manager
13:17jhfordok, it's not happening today :/
13:17jhford ?, in null.<anonymous>
13:17jhfordthanks node!
13:50rwoodwcosta: thank you for the tc configs review
14:02wcostayw
14:41tomprinceIs it possible to get taskcluster to trigger on user repositories on hg.m.o? I&#39;d like to create a branch where I can experiment with taskclusterizing Thunderbird.
14:43dustinwe can set that up for you
14:44dustintomprince: if you make a PR to add a clause to https://github.com/taskcluster/mozilla-taskcluster/blob/master/src/config/default.yml#L75 we can merge it
14:44dustin.. and probably break something deploying it, but we&#39;ll see
15:02jhfordwho&#39;s joining us from Toronto
15:23tomprincedustin: Should the key be of the form `users/<username>/<repo>` then? I tried looking through the code to figure out where that was turned into something that the pushlog monitor looked at, but it appeared that the pushlog monitor just looked at the DB which wasn&#39;t initialized anywhere.
15:24dustingood question, let me peek
15:27dustingarndt: ^^ is it your memory that one would manually insert a row into mongodb?
15:28garndthrm, so the way I&#39;ve done it in the past is there is a script to run that populates that DB with projects that treeherder knows about (terrible, I know). I suppose you could also manually add it
15:30dustinhttps://github.com/taskcluster/mozilla-taskcluster/blob/master/src/bin/import_repositories.js
15:30dustinlooks like that won&#39;t delete rows though
15:30dustinso manually adding should be OK
15:30garndtyea
15:30garndtI think so too
15:30dustintomprince: so, yeah, use the key you suggested
15:31tomprincedustin: K. Thanks. I&#39;ll send a PR in a little bit.
15:57jonasfjstandups: catched up on new artifacts API and talked worker-id uniqueness with jhford
15:57standupsOk, submitted #48073 for https://www.standu.ps/user/jonasfj/
15:58dustinstandups, wow, haven&#39;t seen that in a while :)
15:58standupsOk, submitted #48074 for https://www.standu.ps/user/dustin/
16:00jonasfjyeah, I&#39;m getting back to old habits with my friend standups
16:01bstackstandups: sit down, you&#39;re blocking the view.
16:01standupsOk, submitted #48076 for https://www.standu.ps/user/bstack/
16:07rwoodwcosta: ping
16:14wcostarwood: pong (at gym)
16:14rwoodwcosta: haha, I landed my latest tc configs and broke autoland, they&#39;re being backed out, just wondered if you have some time later to check it out, I&#39;m not sure why/how it broke
16:15rwoodBug 1378451
16:15firebothttps://bugzil.la/1378451 ASSIGNED, rwood@mozilla.com Taskcluster/buildbot configs for new talos perf-reftest-singletons suite
16:16wcostarwood: sure, I look when I am back
16:16rwoodwcosta: thank you sir! have a good workout
16:16wcostaThanks
16:47Callekdustin: can you or someone fix/restart this decision task: https://treeherder.mozilla.org/#/jobs?repo=date&revision=6ce24ffac0483f462ad033e3ff632b9032adc91f
16:49Callek...[taskcluster:error] Task was aborted because states could not be created successfully. Error calling &#39;link&#39; for localLiveLog : (HTTP code 404) no such container - invalid header field value &quot;oci runtime error: container_linux.go:247: starting container process caused \&quot;process_linux.go:258: applying cgroup configuration for process caused \\\&quot;open
16:49Callek/sys/fs/cgroup/cpuset/docker/cpuset.cpus: no such file or directory\\\&quot;\&quot;\n&quot;
16:50bstackhmm
16:50bstackthat seems not-good
16:50bstackthis seems like something specific to that worker I think?
16:50bstackdo we see stuff like this frequently?
16:51garndtCallek: I killed the instance
16:51Callekbstack: agreed on not good, first time I&#39;ve ever seen that message, and this is on a date decision task I just pushed
16:51Callekgarndt: I thought you were PTO this week
16:51garndtit happens, low percent of number of tasks/workers we run, but it does happen
16:51garndtCallek: starting later today :)
16:51Callekgarndt: can someone re-run the decision task?
16:51* Callek isn&#39;t sure he has the scopes to do that in any way I know how
16:51bstackgarndt: ok, so the process here is to kill that instance :)
16:52bstackwill do so in the future
16:54garndtbstack: yea, this is a state where docker becomes stupid....happens maybe a couple of times per week, usually not too noticeable, but definitely notcieable when it hits the decision worker type
16:54bstackkk, sounds good
17:22garndtCallek: sorry, I didn&#39;t respond at the time, but either my retrigger went through successfully, or someon else retriggered it
17:22garndteither way, you should be good
17:22Callekgarndt: thanks!
17:23garndtnp
17:23jlorenzogarndt: hey! I won&#39;t be able to attend to the meeting in 10 minutes. There&#39;s one test failure we discovered on tc-windows https://tools.taskcluster.net/groups/FGJqil2aTZeAb1pT9ye2CA/tasks/a04m1HI8S96BPdKDWXJ7Lg/runs/0/logs/public%2Flogs%2Flive.log . The dev of the test would like to get more logs by dumping strings, but it seems these logs aren&#39;t uploaded on
17:23jlorenzoTC. I&#39;m not sure in which component I should file the bug
17:24catleelike he wants to output a new artifact?
17:24jlorenzohe just wants to dump strings
17:25jlorenzofrom what I understood in the logs, these strings are output elsewhere
17:25garndtyea, it sounds like he should redirect that to a file in a path the task already knows to upload. It looks like the logs directory is specified to be uploaded on task completion
17:25garndthttps://tools.taskcluster.net/groups/FGJqil2aTZeAb1pT9ye2CA/tasks/a04m1HI8S96BPdKDWXJ7Lg/runs/0/artifacts
17:25jlorenzo{&quot;thread&quot;: &quot;Thread-610&quot;, &quot;level&quot;: &quot;INFO&quot;, &quot;pid&quot;: 3524, &quot;component&quot;: &quot;mozcrash&quot;, &quot;source&quot;: &quot;XPCShell&quot;, &quot;time&quot;: 1498845666870, &quot;action&quot;: &quot;log&quot;, &quot;message&quot;: &quot;Using tests\\bin\\minidumpwriter.exe to write a dump to c:\\users\\genericworker\\appdata\\local\\temp\\xpc-other-eb28yz\\285cf57f-66e6-4110-b9a0-59ab779ad1df.dmp for [2920]&quot;}
17:26Callekjlorenzo: oooo I think I saw a bug on that recently... Bug 1378251
17:26firebothttps://bugzil.la/1378251 FIXED, gbrown@mozilla.com Windows taskcluster builds fail to upload minidump artifacts
17:26jlorenzooh that looks like it
17:26* Callek isn&#39;t sure if that applies to *tests* though
17:27jlorenzookay, it landed 5 days ago. My last try was during the All Hands
17:27jlorenzoI&#39;ll give it a try tomorrow
17:28jlorenzothanks!
17:39wcostarwood: do you have TH link?
17:50rwoodwcosta: https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=feaa8a920f0687dcb9d79987587a2add8d811fb9&selectedJob=113372246
17:56wcostarwood: I think you have to add &quot;default: &#39;built-projects&#39; in run-on-projects: by-test-platform
17:56wcostaI noticed this in review, but thought parser would assume &quot;default&quot; behavior if nothing found
18:02rwoodwcosta: ok cool thank you! I&#39;ll add that and land on try
18:28bstackjonas: when we&#39;ve talked about redoing backfilling before, you&#39;ve mentioned that you think it would be better to query hg pushlog instead of treeherder to find previous pushes, right?
18:30bstackjonasfj, not just jonas ^
18:50bstackaki: if that seems like the best way forward we can do something like that.
18:51bstackwould it be generally helpful in more cases than the backfill one?
18:51akinot sure. pretty sure we&#39;ll have instances where there are more than one graph per push_id, so that may not be the best solution
18:52akie.g., beta promotion graph + on-push graph
18:53bstackwill jobs from those different graphs all show up under one push in TH?
18:54dustinyes
18:54bstackif so they&#39;re kinda one entity for the purposes of backfilling I guess
18:54akiyes. maybe the decision task will only update the index if it&#39;s given push info
18:54akiso we don&#39;t try to update the release graph with on-push tasks
18:54dustinsounds like a job for json-e :)
18:54bstackI think my thinking here is that the &quot;unit&quot; of backfilling _is_ a treeherder push
18:54aki:)
18:54bstackand so that&#39;s the source of truth we should use to do things with backfilling
18:54bstackdoes that make sense?
18:54akii think it&#39;s a graph on a treeherder push
18:55akiand there may be multiple graphs per treeherder push
18:55dustin{$if: &quot;pushid != 0&quot;, then: &#39;route.index.foo.bar.${pushid}&#39;}
18:56bstackbut using pushlog instead of treeherder would be nice
18:56akiyeah, that was my only real motivation for commenting on it at all. i don&#39;t have a strong opinion here
18:58bstackbackfilling continues to have a really high impedance mismatch between all of the systems we have
19:00bstackooooh wait, I think we do index under pushlog_id already, just not in the gecko index stuff
19:00bstackthis might work out afterall
19:00bstackalthough it is under a revision in the namespace for some reason
19:02* bstack stops thinking out loud
19:03dustinyeah, there&#39;s definitely an area deeply in the weeds that pulls together disparate sets of information like this
19:04catleespeaking of which...
19:04catleehttps://tools.taskcluster.net/index/artifacts/gecko.v2.mozilla-central.revision
19:04catlee&quot;More namespaces&quot; doesn&#39;t seem to work
19:06dustinfile a bug plz
19:06dustinwe really should implement expiration :)
19:07catleeyes...so many top level namespaces
19:09catleeincluding &quot;deleteThisAtWill&quot;
19:11dustinhaha
19:11dustingood luck, since there&#39;s no delete API
19:46wcostawhimboo: ping
19:57whimboowcosta: hey
19:58wcostawhimboo: i can&#39;t see the failures from the link you provided, i suspect i miss something
20:24whimboowcosta: hm
20:24whimboohttps://treeherder.mozilla.org/#/jobs?repo=mozilla-central&filter-searchStr=firefox%20ui%20os%20x&filter-tier=1&filter-tier=2&filter-tier=3&bugfiler&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=exception&filter-resultStatus=retry&filter-resultStatus=usercancel&filter-resultStatus=runnable
20:24whimboowhat about that
20:24whimboosimply scroll down
20:37mismithHi, would this be the right place to request a scope for my Mozilla account? I tried to use the &quot;Add new jobs&quot; UI on Treeherder to manually trigger a web platform tests chunk on try, but got back a message saying that I didn&#39;t have any of the scopes necessary to add jobs at any priority level.
20:39dustinmismith: were you logged in with the same LDAP account that has push permissions?
20:41mismithdustin: Aah, I was not. Thanks.
20:53wcostawhimboo: found it, the tooltool cache directory is set to /home/worker/tooltool-cache https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/configs/firefox_ui_tests/taskcluster.py#19 but as macosx tests run on a real machine, it should be /builds/tooltool_cache
20:54wcostabut I don&#39;t think the task is failing because of this, though
20:55whimboowcosta: hm, i thought that I removed this setting a while ago. doesn&#39;t look like
20:55whimboowcosta: so maybe it fials because it cannot recursively create this folder?
20:57wcostawhimboo: this only affects tooltool caching, probably this is happening since migration, so if this was the cause of task failure, it should be failing since then
20:57wcostaanyway, I will fix it
21:01whimboowcosta: i enabled our tests after the migration
21:01whimboothey never run via buildbot actually
21:15wcostaahhhh
21:20Aryxhi, does pulling the aws data work as expected? gecko-t-linux-large and gecko-t-linux-xlarge look a tad increased when one checks pending vs running
21:24whimboowcosta: so if its something you cannot cover, i will fix it. just let me know on the bug
21:25wcostawhimboo: ok, but I can fix it too if you want, np, it is a simple patch, or you can just r? me
21:26whimboowcosta: fine with me. I&#39;m only partially aroudn this week
21:26wcostawhimboo: so, never mind, I fix it
21:26whimboothanks!
12 Jul 2017
No messages
   
Last message: 73 days and 7 hours ago