*** lantw44 has quit IRC | 01:04 | |
*** lantw44 has joined #buildstream | 01:04 | |
*** nimish has joined #buildstream | 02:11 | |
*** nimish has quit IRC | 02:13 | |
*** nimish has joined #buildstream | 02:35 | |
*** juanalday has quit IRC | 02:47 | |
*** nimish has quit IRC | 03:21 | |
*** tristan has joined #buildstream | 07:50 | |
*** tristan has quit IRC | 07:54 | |
*** tristan has joined #buildstream | 08:07 | |
*** toscalix has joined #buildstream | 08:42 | |
gitlab-br-bot | tristanvb 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/1172 | 08:47 |
---|---|---|
gitlab-br-bot | tristanvb 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/1173 | 08:55 |
*** ChanServ sets mode: +o tristan | 08:58 | |
tristan | juergbi, Turns out the bug was fixed accidentally in master (by way of implementing configurable warnings) | 08:58 |
tristan | Still adding the regression test to master | 08:58 |
juergbi | just saw that, so you were testing 1.2? | 08:59 |
tristan | I was testing master first | 08:59 |
tristan | that's why I couldnt reproduce | 08:59 |
juergbi | ah, but you initially saw the issue on 1.2? | 08:59 |
tristan | I am *using* 1.2 which is where it blew up in my face | 08:59 |
tristan | yeah | 08:59 |
juergbi | I see | 08:59 |
tristan | Hmmmm | 09:12 |
tristan | juergbi, is the parallel tests causing failures in CI ? | 09:12 |
juergbi | haven't seen any so far | 09:13 |
juergbi | where have you seen a potential issue? | 09:13 |
tristan | Lemme recheck this on my branch https://gitlab.com/BuildStream/buildstream/-/jobs/165828538 | 09:13 |
tristan | That seems to be having a ton of failures, but all the branch does is add a new test | 09:13 |
tristan | weird | 09:13 |
tristan | lemme re-run the full suite locally, maybe I inadvertently screwed up something | 09:14 |
juergbi | oh, odd, fedora-29 seems fine | 09:14 |
juergbi | may need to wait for the end of the CI job to check the error messages | 09:14 |
tristan | yeah certainly looks unjustified to have that many failing | 09:15 |
tristan | unless like I somehow mutated something in the cli fixture from my test causing almost everything to break afterwards | 09:16 |
juergbi | seems likely to be triggered by parallel testing (even though the underlying cause _may_ be something else) | 09:16 |
juergbi | but that's the first time I see such an issue | 09:17 |
juergbi | it'll be 'finished' soon, let's see | 09:17 |
tristan | It also appears that only [gw1] is affected (still can't find a failing [gw0] test) | 09:19 |
juergbi | yes, yet not all of gw1 | 09:19 |
juergbi | we might still have issues where some tests depend on each other, i.e., they fail when run individually or in the 'wrong' order | 09:20 |
juergbi | I fixed one of those and haven't noticed any other with lots of local parallel testing, but maybe there are more | 09:20 |
* juergbi wonders whether there is an easy way to run all tests in separate sessions to check for such issues | 09:20 | |
juergbi | RuntimeError: set_wakeup_fd only works in main thread | 09:22 |
juergbi | that'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 |
tristan | rrrright, so `pytest -n 2` is using threads for this, and not separate isolated processes ? | 09:30 |
tristan | Seems like that should cause tests to fail most of the time though | 09:31 |
tristan | not this rarely | 09:31 |
*** phildawson has joined #buildstream | 09:41 | |
juergbi | tristan: no, it's using separate processes | 09:42 |
*** phildawson has quit IRC | 09:42 | |
*** phildawson has joined #buildstream | 09:42 | |
juergbi | completely separate python instances, afaik | 09:42 |
tristan | Yeah that would make more sense | 09:43 |
juergbi | that error is something I've seen before, without parallel testing | 09:43 |
juergbi | without parallel testing it will fail almost all (eventloop using) tests | 09:43 |
juergbi | with parallel testing, it apparently only affects a single process, which makes sense | 09:43 |
tristan | So once it happens in a session, it happens for the rest of anything which uses the event loop ? | 09:44 |
juergbi | but I hadn't seen that error for quite a while | 09:44 |
juergbi | I think so | 09:44 |
*** raoul has joined #buildstream | 09:54 | |
gitlab-br-bot | tristanvb 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/1173 | 10:05 |
*** tpollard has joined #buildstream | 10:06 | |
gitlab-br-bot | tristanvb closed issue #926 (Subproject overlap policy is inherited by including projects) on buildstream https://gitlab.com/BuildStream/buildstream/issues/926 | 10:08 |
gitlab-br-bot | martinblanchard 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/1174 | 10:11 |
*** jonathanmaw has joined #buildstream | 10:15 | |
*** tristan has quit IRC | 10:16 | |
gitlab-br-bot | tristanvb 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/1172 | 10:28 |
*** lachlan has joined #buildstream | 10:31 | |
*** lachlan has quit IRC | 10:34 | |
*** lachlan has joined #buildstream | 11:14 | |
*** tristan has joined #buildstream | 11:39 | |
*** raoul has quit IRC | 11:52 | |
*** lachlan has quit IRC | 11:56 | |
*** lachlan has joined #buildstream | 11:58 | |
*** lachlan has quit IRC | 12:03 | |
*** lachlan has joined #buildstream | 12:06 | |
*** lachlan has quit IRC | 12:12 | |
*** alatiera has joined #buildstream | 12:15 | |
*** lachlan has joined #buildstream | 12:25 | |
* tlater[m] is just reading through our repository email settings | 12:38 | |
tlater[m] | Why do we enable pipeline/push emails? | 12:39 |
tlater[m] | I think a lot of the pointless noise comes from those | 12:39 |
*** nimish has joined #buildstream | 12:42 | |
*** lachlan has quit IRC | 12:46 | |
*** ChanServ sets mode: +o tristan | 12:47 | |
tristan | tlater[m], I don't receive those unless I am the owner of the pipeline | 12:47 |
laurence | you only get them on your own MRs | 12:49 |
laurence | speaking of which would someone mind merging this note in the contribution guide? https://gitlab.com/BuildStream/buildstream/merge_requests/1171 | 12:49 |
laurence | it's about WIP MRs | 12:49 |
jmac | I get notifications about pushes to any MR I've commented on | 12:51 |
jmac | I don't get them about pushes to my own MRs, gitlab is clever enough to filter them out | 12:52 |
tlater[m] | Well, most of what the buildstream-notifications list received were those notifications | 12:55 |
tlater[m] | Just on a project-wide level | 12:55 |
jmac | Oh, I didn't realise this was about buildstream-notifications | 12:56 |
* tlater[m] is frankly not sure how it ties into the infrastructure yet | 12:59 | |
* tlater[m] wonders if this is documented somewhere | 12:59 | |
*** raoul has joined #buildstream | 12:59 | |
juergbi | tlater[m]: maybe one of the hooks here? https://gitlab.com/BuildStream/buildstream/settings/integrations | 13:12 |
juergbi | ah no, rather https://gitlab.com/BuildStream/buildstream/services/emails_on_push/edit | 13:12 |
juergbi | and https://gitlab.com/BuildStream/buildstream/services/pipelines_email/edit | 13:12 |
tlater[m] | Ah, thanks juergbi | 13:14 |
* tlater[m] didn't realize those links were clickable T.T | 13:15 | |
tlater[m] | Whelp, the buildstream-notofications list should now officially remain silent | 13:16 |
*** milloni has left #buildstream | 13:28 | |
*** nimish has quit IRC | 13:40 | |
tpollard | looks like Marge is having some trouble | 13:57 |
tpollard | https://gitlab.com/BuildStream/buildstream/merge_requests/1171#note_144067746 are we expecting it to be working? does it need a timeout increase? | 13:57 |
laurence | yeah, perhaps we do. also just thought i think marge bot may also need permissions to merge | 13:59 |
laurence | she's just a dev at the moment | 13:59 |
laurence | juergbi, tristan, jjardon, if you have permissions? | 14:00 |
laurence | also i may need to ask Codethink Ops about the timeout setting | 14:01 |
laurence | the default timeout is 15 mins | 14:02 |
laurence | I'll get this changed to 60 mins? | 14:03 |
laurence | or 90 mins? | 14:03 |
tpollard | in recent times 90 mins at least, but we have the parallel improvements now | 14:08 |
*** lachlan has joined #buildstream | 14:10 | |
gitlab-br-bot | raoul.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/1174 | 14:14 |
tpollard | it would be nice if the we could cancel a running/started job when a branch has been pushed again before the original has finished CI | 14:15 |
tpollard | *automatically | 14:15 |
tpollard | I've tried to get into the habit of manually doing it when I force push a quick amend etc | 14:15 |
*** lachlan has quit IRC | 14:16 | |
*** lachlan has joined #buildstream | 14:21 | |
gitlab-br-bot | jmacarthur 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/1174 | 14:23 |
*** lachlan has quit IRC | 14:25 | |
*** nimish has joined #buildstream | 14:27 | |
gitlab-br-bot | jmacarthur 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/1174 | 14: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 #buildstream | 14:47 | |
juergbi | laurence: I've granted bst-marge-bot permission to merge to protected branches | 14:50 |
laurence | thanksĀ¬! | 14:50 |
juergbi | (still developer but that should suffice) | 14:50 |
laurence | i have also amended the timeout to 90 mins | 14:50 |
juergbi | great | 14:50 |
laurence | i will assign the contributing MR to her now | 14:51 |
*** nimish has quit IRC | 14:52 | |
*** nimish has joined #buildstream | 14:53 | |
*** sebastian has quit IRC | 14:59 | |
*** lachlan has quit IRC | 15:02 | |
gitlab-br-bot | jmacarthur 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/1174 | 15:14 |
*** lachlan has joined #buildstream | 15:16 | |
*** nimish has quit IRC | 15:37 | |
* tlater[m] recalls some discussion about sorting out the "default" BuildStream plugins | 15:45 | |
tlater[m] | Do we have an issue about that? | 15:45 |
tlater[m] | phildawson, WSalmon were involved, I think | 15:45 |
WSalmon | phildawson, has been doing the lifting, i just say thing to make him more work some times | 15:50 |
laurence | tlater[m], I believe that Chiara did a good job of outlining plug-ins on the list | 15:51 |
laurence | not sure what you mean about 'defaults' exactly | 15:51 |
laurence | but phildawson has a list of the migration plan which is due to be shared publicly soon | 15:51 |
laurence | i tried to collate info here - https://mail.gnome.org/archives/buildstream-list/2018-December/msg00145.html | 15: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 repository | 15:53 |
tlater[m] | i.e., any plugins not in bst-external | 15:53 |
laurence | aha, i see | 15:55 |
*** sebastian has joined #buildstream | 16:12 | |
gitlab-br-bot | marge-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/1171 | 16:24 |
tpollard | marge bot \o/ | 16:26 |
laurence | ahh sweet | 16:26 |
aevri | huzzah for marge :) | 16:29 |
phildawson | \o/ | 16:30 |
* tlater[m] still wonders what this "marge" is | 16:32 | |
* tlater[m] expects to have a "get off my lawn" moment | 16:32 | |
phildawson | tlater[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 |
phildawson | But who's CI finishes first seems to only be loosely correlated to who pushed first :P | 16:36 |
tlater[m] | Prefixing all your branches with "!!" is a good survival strategy. | 16:37 |
laurence | Once 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 |
laurence | I'm pretty sure that's the rub, tlater[m] | 16:37 |
laurence | some of the details may be a little off there | 16:37 |
laurence | I'm going to post to the list about it now anywa | 16:37 |
laurence | y | 16:37 |
tlater[m] | Ah, haha, I'm more up to date than I thought I was | 16:37 |
*** lachlan has quit IRC | 16:40 | |
*** toscalix has quit IRC | 16:48 | |
* tlater[m] realizes that marge is basically the solution to a problem gitlab should have thought of | 16:49 | |
laurence | yes, should be default in gitlab | 16:49 |
*** lachlan has joined #buildstream | 16:51 | |
jmac | Oh, they're quite aware it's a problem, they just haven't fixed it yet | 16:53 |
jmac | Margebot looks great though | 16:54 |
*** tpollard has quit IRC | 17:01 | |
*** sebastian has quit IRC | 17:17 | |
*** lachlan has quit IRC | 17:36 | |
*** jonathanmaw has quit IRC | 17:44 | |
*** lachlan has joined #buildstream | 17:46 | |
*** lachlan has quit IRC | 18:06 | |
*** lachlan has joined #buildstream | 18:15 | |
*** raoul has quit IRC | 18:18 | |
*** alatiera has quit IRC | 18:40 | |
*** nimish has joined #buildstream | 18:49 | |
*** lachlan has quit IRC | 19:10 | |
*** lachlan has joined #buildstream | 19:16 | |
*** lachlan has quit IRC | 20: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 |
tristan | doras[m], bst show | 22:19 |
tristan | there is no way to tell with bst show whether the artifact can be downloaded, though | 22:20 |
doras[m] | I need this information for automation. Does "bst show" give a clear indication? | 22:22 |
tristan | bst show is intended to be scriptable, as such it has a --format option which lets you control and parse the output | 22:23 |
tristan | for this field though, you will want %{state}, and this one is a bit tricky I guess | 22:23 |
tristan | but ultimately, it will say 'cached' if the element is cached | 22:23 |
tristan | if it is not cached, it is either buildable, waiting, fetch needed or inconsistent | 22:24 |
tristan | again, you cannot tell if it is downloadable because we only ever check that on demand | 22:24 |
doras[m] | That should be enough. Thanks! | 22:25 |
*** tristan has quit IRC | 23:18 | |
*** sebastian has joined #buildstream | 23:30 | |
*** nimish has quit IRC | 23:45 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!