IRC logs for #buildstream for Friday, 2019-02-22

*** lantw44 has quit IRC01:04
*** lantw44 has joined #buildstream01:04
*** nimish has joined #buildstream02:11
*** nimish has quit IRC02:13
*** nimish has joined #buildstream02:35
*** juanalday has quit IRC02:47
*** nimish has quit IRC03:21
*** tristan has joined #buildstream07:50
*** tristan has quit IRC07:54
*** tristan has joined #buildstream08:07
*** toscalix has joined #buildstream08:42
gitlab-br-bottristanvb opened MR !1172 (tristan/fix-overlap-subproject-policy-1.2->bst-1.2: Observe fail-on-overlap policy on building element's project) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/117208:47
gitlab-br-bottristanvb opened MR !1173 (tristan/fix-overlap-subproject-policy->master: tests/frontend/overlaps.py: Added regression test for cross project overlaps) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/117308:55
*** ChanServ sets mode: +o tristan08:58
tristanjuergbi, Turns out the bug was fixed accidentally in master (by way of implementing configurable warnings)08:58
tristanStill adding the regression test to master08:58
juergbijust saw that, so you were testing 1.2?08:59
tristanI was testing master first08:59
tristanthat's why I couldnt reproduce08:59
juergbiah, but you initially saw the issue on 1.2?08:59
tristanI am *using* 1.2 which is where it blew up in my face08:59
tristanyeah08:59
juergbiI see08:59
tristanHmmmm09:12
tristanjuergbi, is the parallel tests causing failures in CI ?09:12
juergbihaven't seen any so far09:13
juergbiwhere have you seen a potential issue?09:13
tristanLemme recheck this on my branch https://gitlab.com/BuildStream/buildstream/-/jobs/16582853809:13
tristanThat seems to be having a ton of failures, but all the branch does is add a new test09:13
tristanweird09:13
tristanlemme re-run the full suite locally, maybe I inadvertently screwed up something09:14
juergbioh, odd, fedora-29 seems fine09:14
juergbimay need to wait for the end of the CI job to check the error messages09:14
tristanyeah certainly looks unjustified to have that many failing09:15
tristanunless like I somehow mutated something in the cli fixture from my test causing almost everything to break afterwards09:16
juergbiseems likely to be triggered by parallel testing (even though the underlying cause _may_ be something else)09:16
juergbibut that's the first time I see such an issue09:17
juergbiit'll be 'finished' soon, let's see09:17
tristanIt also appears that only [gw1] is affected (still can't find a failing [gw0] test)09:19
juergbiyes, yet not all of gw109:19
juergbiwe might still have issues where some tests depend on each other, i.e., they fail when run individually or in the 'wrong' order09:20
juergbiI fixed one of those and haven't noticed any other with lots of local parallel testing, but maybe there are more09:20
* juergbi wonders whether there is an easy way to run all tests in separate sessions to check for such issues09:20
juergbiRuntimeError: set_wakeup_fd only works in main thread09:22
juergbithat's an old sporadic issue independent of parallel testing, isn't it?09:22
juergbi(but likely only affects one process/session at a time, hence only [some] gw1 tests failing)09:23
tristanrrrright, so `pytest -n 2` is using threads for this, and not separate isolated processes ?09:30
tristanSeems like that should cause tests to fail most of the time though09:31
tristannot this rarely09:31
*** phildawson has joined #buildstream09:41
juergbitristan: no, it's using separate processes09:42
*** phildawson has quit IRC09:42
*** phildawson has joined #buildstream09:42
juergbicompletely separate python instances, afaik09:42
tristanYeah that would make more sense09:43
juergbithat error is something I've seen before, without parallel testing09:43
juergbiwithout parallel testing it will fail almost all (eventloop using) tests09:43
juergbiwith parallel testing, it apparently only affects a single process, which makes sense09:43
tristanSo once it happens in a session, it happens for the rest of anything which uses the event loop ?09:44
juergbibut I hadn't seen that error for quite a while09:44
juergbiI think so09:44
*** raoul has joined #buildstream09:54
gitlab-br-bottristanvb merged MR !1173 (tristan/fix-overlap-subproject-policy->master: tests/frontend/overlaps.py: Added regression test for cross project overlaps) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/117310:05
*** tpollard has joined #buildstream10:06
gitlab-br-bottristanvb closed issue #926 (Subproject overlap policy is inherited by including projects) on buildstream https://gitlab.com/BuildStream/buildstream/issues/92610:08
gitlab-br-botmartinblanchard opened MR !1174 (mablanch/823-action-cache-instance-name->master: Fix and improve instances support for remote-execution.) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/117410:11
*** jonathanmaw has joined #buildstream10:15
*** tristan has quit IRC10:16
gitlab-br-bottristanvb merged MR !1172 (tristan/fix-overlap-subproject-policy-1.2->bst-1.2: Observe fail-on-overlap policy on building element's project) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/117210:28
*** lachlan has joined #buildstream10:31
*** lachlan has quit IRC10:34
*** lachlan has joined #buildstream11:14
*** tristan has joined #buildstream11:39
*** raoul has quit IRC11:52
*** lachlan has quit IRC11:56
*** lachlan has joined #buildstream11:58
*** lachlan has quit IRC12:03
*** lachlan has joined #buildstream12:06
*** lachlan has quit IRC12:12
*** alatiera has joined #buildstream12:15
*** lachlan has joined #buildstream12:25
* tlater[m] is just reading through our repository email settings12:38
tlater[m]Why do we enable pipeline/push emails?12:39
tlater[m]I think a lot of the pointless noise comes from those12:39
*** nimish has joined #buildstream12:42
*** lachlan has quit IRC12:46
*** ChanServ sets mode: +o tristan12:47
tristantlater[m], I don't receive those unless I am the owner of the pipeline12:47
laurenceyou only get them on your own MRs12:49
laurencespeaking of which would someone mind merging this note in the contribution guide? https://gitlab.com/BuildStream/buildstream/merge_requests/117112:49
laurenceit's about WIP MRs12:49
jmacI get notifications about pushes to any MR I've commented on12:51
jmacI don't get them about pushes to my own MRs, gitlab is clever enough to filter them out12:52
tlater[m]Well, most of what the buildstream-notifications list received were those notifications12:55
tlater[m]Just on a project-wide level12:55
jmacOh, I didn't realise this was about buildstream-notifications12:56
* tlater[m] is frankly not sure how it ties into the infrastructure yet12:59
* tlater[m] wonders if this is documented somewhere12:59
*** raoul has joined #buildstream12:59
juergbitlater[m]: maybe one of the hooks here? https://gitlab.com/BuildStream/buildstream/settings/integrations13:12
juergbiah no, rather https://gitlab.com/BuildStream/buildstream/services/emails_on_push/edit13:12
juergbiand https://gitlab.com/BuildStream/buildstream/services/pipelines_email/edit13:12
tlater[m]Ah, thanks juergbi13:14
* tlater[m] didn't realize those links were clickable T.T13:15
tlater[m]Whelp, the buildstream-notofications list should now officially remain silent13:16
*** milloni has left #buildstream13:28
*** nimish has quit IRC13:40
tpollardlooks like Marge is having some trouble13:57
tpollardhttps://gitlab.com/BuildStream/buildstream/merge_requests/1171#note_144067746 are we expecting it to be working? does it need a timeout increase?13:57
laurenceyeah, perhaps we do. also just thought i think marge bot may also need permissions to merge13:59
laurenceshe's just a dev at the moment13:59
laurencejuergbi, tristan, jjardon, if you have permissions?14:00
laurencealso i may need to ask Codethink Ops about the timeout setting14:01
laurencethe default timeout is 15 mins14:02
laurenceI'll get this changed to 60 mins?14:03
laurenceor 90 mins?14:03
tpollardin recent times 90 mins at least, but we have the parallel improvements now14:08
*** lachlan has joined #buildstream14:10
gitlab-br-botraoul.hidalgocharman approved MR !1174 (mablanch/823-action-cache-instance-name->master: Fix and improve instances support for remote-execution.) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/117414:14
tpollardit would be nice if the we could cancel a running/started job when a branch has been pushed again before the original has finished CI14:15
tpollard*automatically14:15
tpollardI've tried to get into the habit of manually doing it when I force push a quick amend etc14:15
*** lachlan has quit IRC14:16
*** lachlan has joined #buildstream14:21
gitlab-br-botjmacarthur approved MR !1174 (mablanch/823-action-cache-instance-name->master: Fix and improve instances support for remote-execution.) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/117414:23
*** lachlan has quit IRC14:25
*** nimish has joined #buildstream14:27
gitlab-br-botjmacarthur approved MR !1174 (mablanch/823-action-cache-instance-name->master: Fix and improve instances support for remote-execution.) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/117414:27
tlater[m]tpollard: In the benchmarks repository we've been seeing effects that suggest cancelling doesn't actually do anything.14:43
tlater[m]That said, +1, put a feature request in :)14:43
*** lachlan has joined #buildstream14:47
juergbilaurence: I've granted bst-marge-bot permission to merge to protected branches14:50
laurencethanksĀ¬!14:50
juergbi(still developer but that should suffice)14:50
laurencei have also amended the timeout to 90 mins14:50
juergbigreat14:50
laurencei will assign the contributing MR to her now14:51
*** nimish has quit IRC14:52
*** nimish has joined #buildstream14:53
*** sebastian has quit IRC14:59
*** lachlan has quit IRC15:02
gitlab-br-botjmacarthur merged MR !1174 (mablanch/823-action-cache-instance-name->master: Fix and improve instances support for remote-execution.) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/117415:14
*** lachlan has joined #buildstream15:16
*** nimish has quit IRC15:37
* tlater[m] recalls some discussion about sorting out the "default" BuildStream plugins15:45
tlater[m]Do we have an issue about that?15:45
tlater[m]phildawson, WSalmon were involved, I think15:45
WSalmonphildawson, has been doing the lifting, i just say thing to make him more work some times15:50
laurencetlater[m], I believe that Chiara did a good job of outlining plug-ins on the list15:51
laurencenot sure what you mean about 'defaults' exactly15:51
laurencebut phildawson has a list of the migration plan which is due to be shared publicly soon15:51
laurencei tried to collate info here - https://mail.gnome.org/archives/buildstream-list/2018-December/msg00145.html15:52
tlater[m]laurence: tyvm, just what I was looking for :)15:53
tlater[m]By "default" I meant what was included in the buildstream main repository15:53
tlater[m]i.e., any plugins not in bst-external15:53
laurenceaha, i see15:55
*** sebastian has joined #buildstream16:12
gitlab-br-botmarge-bot123 merged MR !1171 (laurence/update-readme->master: Update CONTRIBUTING.rst to add paragraph on new MR policy) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/117116:24
tpollardmarge bot \o/16:26
laurenceahh sweet16:26
aevrihuzzah for marge :)16:29
phildawson\o/16:30
* tlater[m] still wonders what this "marge" is16:32
* tlater[m] expects to have a "get off my lawn" moment16:32
phildawsontlater[m], once an mr has been approved, you can assign it to marge and she will handle basic rebasing and retesting then merging that you end up needing to do when someone else has beaten you to the merge.16:34
tlater[m]Back in my day you learned just to push ready branches and restart CI fastest if it broke!16:35
phildawsonBut who's CI finishes first seems to only be loosely correlated to who pushed first :P16:36
tlater[m]Prefixing all your branches with "!!" is a good survival strategy.16:37
laurenceOnce you have the MR reviewed and approved to land, simply assign to Marge instead of hitting merge yourself, and she will handle the management of the current queue of MRs being set to merge. This means that if one pipeline succeeds and something is merged, other MRs are automatically re-based and set to merge, so you don't have to deal with this hassle.16:37
laurenceI'm pretty sure that's the rub, tlater[m]16:37
laurencesome of the details may be a little off there16:37
laurenceI'm going to post to the list about it now anywa16:37
laurencey16:37
tlater[m]Ah, haha, I'm more up to date than I thought I was16:37
*** lachlan has quit IRC16:40
*** toscalix has quit IRC16:48
* tlater[m] realizes that marge is basically the solution to a problem gitlab should have thought of16:49
laurenceyes, should be default in gitlab16:49
*** lachlan has joined #buildstream16:51
jmacOh, they're quite aware it's a problem, they just haven't fixed it yet16:53
jmacMargebot looks great though16:54
*** tpollard has quit IRC17:01
*** sebastian has quit IRC17:17
*** lachlan has quit IRC17:36
*** jonathanmaw has quit IRC17:44
*** lachlan has joined #buildstream17:46
*** lachlan has quit IRC18:06
*** lachlan has joined #buildstream18:15
*** raoul has quit IRC18:18
*** alatiera has quit IRC18:40
*** nimish has joined #buildstream18:49
*** lachlan has quit IRC19:10
*** lachlan has joined #buildstream19:16
*** lachlan has quit IRC20:54
doras[m]Is there a command that allows me to check if building an element is required?22:15
doras[m]Similarly to the logic in "bst checkout", which shows an error when an element needs to be built first.22:17
tristandoras[m], bst show22:19
tristanthere is no way to tell with bst show whether the artifact can be downloaded, though22:20
doras[m]I need this information for automation. Does "bst show" give a clear indication?22:22
tristanbst show is intended to be scriptable, as such it has a --format option which lets you control and parse the output22:23
tristanfor this field though, you will want %{state}, and this one is a bit tricky I guess22:23
tristanbut ultimately, it will say 'cached' if the element is cached22:23
tristanif it is not cached, it is either buildable, waiting, fetch needed or inconsistent22:24
tristanagain, you cannot tell if it is downloadable because we only ever check that on demand22:24
doras[m]That should be enough. Thanks!22:25
*** tristan has quit IRC23:18
*** sebastian has joined #buildstream23:30
*** nimish has quit IRC23:45

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!