*** bochecha has quit IRC | 00:04 | |
*** nimish has joined #buildstream | 01:02 | |
*** tristan has quit IRC | 01:15 | |
*** nimish has quit IRC | 02:07 | |
*** nimish has joined #buildstream | 02:07 | |
*** xjuan has quit IRC | 02:10 | |
*** nimish has quit IRC | 02:56 | |
*** nimish has joined #buildstream | 03:14 | |
*** nimish has quit IRC | 03:27 | |
*** tristan has joined #buildstream | 04:10 | |
*** kapil___ has joined #buildstream | 04:35 | |
*** juergbi has quit IRC | 06:29 | |
*** juergbi has joined #buildstream | 08:07 | |
*** juergbi has quit IRC | 08:17 | |
*** juergbi has joined #buildstream | 08:32 | |
*** toscalix has joined #buildstream | 08:54 | |
*** alatiera has joined #buildstream | 08:55 | |
Kinnison | jennis: Do you have a pipeline pass? | 09:27 |
---|---|---|
Kinnison | jennis: if so, merge it :-D | 09:28 |
gitlab-br-bot | jennis merged MR !1082 (jennis/profiling_outputs_binaries->master: Make the profiler output binaries (which can be used to visualise the data)) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1082 | 09:31 |
jennis | Kinnison :) | 09:31 |
*** raoul has joined #buildstream | 09:44 | |
*** bochecha has joined #buildstream | 09:47 | |
*** benschubert has joined #buildstream | 09:54 | |
*** rdale has quit IRC | 10:08 | |
*** jonathanmaw has joined #buildstream | 10:15 | |
*** rdale has joined #buildstream | 10:25 | |
*** nimish has joined #buildstream | 10:28 | |
*** nimish has quit IRC | 10:33 | |
*** nimish has joined #buildstream | 10:33 | |
*** lachlan has joined #buildstream | 10:35 | |
gitlab-br-bot | jjardon opened issue #874 (overnigth test (no cache) are failing: memory exhausted) on buildstream https://gitlab.com/BuildStream/buildstream/issues/874 | 10:39 |
gitlab-br-bot | jjardon closed issue #865 (Overnigth tests are failing: Seems runners doesn't have enough memory) on buildstream https://gitlab.com/BuildStream/buildstream/issues/865 | 10:42 |
*** nimish has quit IRC | 10:48 | |
*** lachlan has quit IRC | 10:48 | |
*** lachlan has joined #buildstream | 10:48 | |
*** nimish has joined #buildstream | 10:49 | |
*** nimish has quit IRC | 10:54 | |
*** nimish has joined #buildstream | 10:54 | |
*** nimish_ has joined #buildstream | 10:58 | |
*** nimish has quit IRC | 10:58 | |
*** nimish_ is now known as nimish | 10:58 | |
valentind | jjardon, since it is llvm that fails on the no cache tests, it seems to me this is also an issue with memory. | 10:59 |
jjardon | Yeah but 16GB of ram should be enough , right? | 11:00 |
valentind | That depends on the number of cores. | 11:02 |
gitlab-br-bot | alex-broad opened issue #875 (Workspace cache continuously invalidated by IDE metadata files) on buildstream https://gitlab.com/BuildStream/buildstream/issues/875 | 11:02 |
*** nimish has quit IRC | 11:04 | |
*** nimish has joined #buildstream | 11:04 | |
valentind | jjardon, I think we should add the logs directory in the artifacts for those builds. | 11:12 |
*** nimish has quit IRC | 11:14 | |
jjardon | valentind: rigth, that maxime have 6 cores / 16GB RAM | 11:14 |
*** nimish has joined #buildstream | 11:15 | |
*** nimish has joined #buildstream | 11:15 | |
jjardon | valentind: also, did you see https://gitlab.com/BuildStream/buildstream/issues/873 ; you have fixed that one before; maybe something change in the CI and we are not using your fixes anymore? | 11:16 |
valentind | jjardon, that looks like a disk full. | 11:17 |
valentind | jjardon, maybe docker images do not get cleaned up correctly. | 11:20 |
jjardon | they do not | 11:20 |
jjardon | gitlab-runner doesn't do it automatically | 11:21 |
jjardon | there is a bug upstream , sec | 11:21 |
jjardon | in the meantime having a cron job doing "docker system prune -a" and "docker volume prune" periodically helps | 11:21 |
jjardon | https://gitlab.com/gitlab-org/gitlab-runner/issues/2980 | 11:22 |
valentind | OK, I will make a timer that does that and deploy it today. | 11:22 |
gitlab-br-bot | valentindavid opened MR !1084 (valentindavid/overnight-tests-logs-artifacts->master: .gitlab-ci.yml: Add overnight tests logs to artifacts.) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1084 | 11:23 |
valentind | jjardon, !1084 | 11:24 |
*** nimish has quit IRC | 11:25 | |
*** nimish has joined #buildstream | 11:27 | |
*** nimish has quit IRC | 11:27 | |
*** nimish has joined #buildstream | 11:28 | |
*** lachlan has quit IRC | 11:28 | |
*** lachlan has joined #buildstream | 11:41 | |
valentind | jjardon, we are already pruning containers on the sleds. | 11:43 |
valentind | Though we do "docker container prune -f" | 11:44 |
*** lachlan has quit IRC | 11:47 | |
*** nimish has quit IRC | 11:48 | |
jjardon | valentind: -a removes more things | 11:48 |
valentind | I will try that. | 11:48 |
*** nimish has joined #buildstream | 11:48 | |
jjardon | also "docker volume prune" | 11:48 |
valentind | Yes. I am deploying it now. | 11:49 |
*** nimish has quit IRC | 11:53 | |
*** nimish has joined #buildstream | 11:53 | |
*** nimish has joined #buildstream | 11:54 | |
gitlab-br-bot | jjardon approved MR !1084 (valentindavid/overnight-tests-logs-artifacts->master: .gitlab-ci.yml: Add overnight tests logs to artifacts.) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1084 | 12:01 |
gitlab-br-bot | jjardon merged MR !1084 (valentindavid/overnight-tests-logs-artifacts->master: .gitlab-ci.yml: Add overnight tests logs to artifacts.) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1084 | 12:01 |
*** nimish has quit IRC | 12:04 | |
*** nimish has joined #buildstream | 12:04 | |
*** lachlan has joined #buildstream | 12:07 | |
valentind | jjardon, I think the volumes were the problem. | 12:31 |
*** nimish has quit IRC | 12:34 | |
*** nimish has joined #buildstream | 12:35 | |
*** nimish has quit IRC | 12:40 | |
*** nimish has joined #buildstream | 12:40 | |
*** nimish has quit IRC | 12:45 | |
*** nimish has joined #buildstream | 12:46 | |
cs-shadow | valentind: you can try `docker system prune --all --force --volumes` to do it in one step | 13:12 |
valentind | cs-shadow, good to know. | 13:12 |
*** nimish has quit IRC | 13:16 | |
*** nimish has joined #buildstream | 13:16 | |
*** nimish has quit IRC | 13:31 | |
*** nimish has joined #buildstream | 13:31 | |
gitlab-br-bot | valentindavid approved MR !1083 (tristan/fix-bzr-race->master: Fix bzr race conditions) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1083 | 13:42 |
*** tristan has quit IRC | 13:47 | |
*** nimish has quit IRC | 13:51 | |
*** nimish has joined #buildstream | 13:52 | |
*** nimish has joined #buildstream | 13:52 | |
*** nimish has quit IRC | 13:57 | |
*** nimish has joined #buildstream | 13:58 | |
*** nimish has quit IRC | 14:03 | |
*** nimish has joined #buildstream | 14:03 | |
*** nimish has joined #buildstream | 14:04 | |
raoul | I'm doing some cache directory reshuffling as part of #870, is there any reason integration tests have their artifact cache in the integration cache instead of the temp folder for the test? From what I can tell it just creates a new one for each test anyway, so it seems redundant | 14:07 |
gitlab-br-bot | Issue #870: Root cache directory https://gitlab.com/BuildStream/buildstream/issues/870 | 14:07 |
jennis | raoul, I thnk it's because many of the artifact tests do share/reuse a cache | 14:13 |
jennis | perhaps you're looking at some examples where they're spinning up a new one each time, but I could be wrong | 14:13 |
jennis | the integration tests* | 14:13 |
* jennis has been battling with artifacts too much | 14:13 | |
raoul | The integration cache context manager explicitly deletes the artifact cache though, so I'm not sure it does | 14:14 |
raoul | it keeps the source dir, but not artifacts | 14:14 |
*** sambishop has quit IRC | 14:14 | |
jennis | perhaps that then, to save re-fetching? | 14:15 |
raoul | yeah that bit makes sense, it's just the artifacts bit I'm questioning | 14:15 |
*** nimish has quit IRC | 14:19 | |
*** nimish has joined #buildstream | 14:19 | |
*** nimish has quit IRC | 14:24 | |
*** nimish has joined #buildstream | 14:24 | |
*** nimish has quit IRC | 14:29 | |
*** nimish has joined #buildstream | 14:30 | |
*** nimish has quit IRC | 14:55 | |
*** nimish has joined #buildstream | 14:56 | |
*** nimish has quit IRC | 15:01 | |
*** nimish has joined #buildstream | 15:01 | |
*** phil has quit IRC | 15:02 | |
*** phil has joined #buildstream | 15:03 | |
*** raoul has quit IRC | 15:03 | |
*** nimish has quit IRC | 15:15 | |
*** nimish has joined #buildstream | 15:16 | |
*** nimish has quit IRC | 15:21 | |
*** nimish has joined #buildstream | 15:22 | |
gitlab-br-bot | richardmaw-codethink opened MR !1085 (richardmaw/centos-oldgit-test-fixes->master: Fix CentOS) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1085 | 15:36 |
*** nimish has quit IRC | 15:47 | |
*** nimish has joined #buildstream | 15:48 | |
*** raoul has joined #buildstream | 15:48 | |
*** phil has quit IRC | 15:49 | |
*** nimish has quit IRC | 15:53 | |
*** nimish has joined #buildstream | 15:54 | |
*** tristan has joined #buildstream | 15:54 | |
*** phil has joined #buildstream | 15:58 | |
tlater[m] | raoul: Back when our base image was gnome-sdk (2GB large!) we needed to keep the artifacts around for whole test modules, or it would just be atrociously slow. | 16:15 |
tlater[m] | Pretty sure that that is why the artifacts are stored like that. | 16:15 |
* tlater[m] incidentally just noticed that this also breaks the remove_artifact helper for integration tests | 16:16 | |
tlater[m] | I'll fix that helper, if you like, would you mind testing if the test suite breaks in horrible ways if we remove that indirection? | 16:17 |
raoul | the remove_artifact method in the Cli class? | 16:18 |
tlater[m] | Yep | 16:18 |
tlater[m] | The artifact cache dir is hardcoded | 16:18 |
tlater[m] | I've already written a fix so I can use it for a test I'm writing | 16:19 |
raoul | ah yes it is | 16:19 |
raoul | which indirection do you mean btw? | 16:19 |
tlater[m] | The thing where we send artifacts to integration-cache when it should really be part of the test-specific tmp dir | 16:20 |
tlater[m] | I don't think this is relevant anymore since the test image is really small these days. | 16:20 |
tlater[m] | And keeping artifacts around can cause tests to succeed when they shouldn't, so we should really make this safe. | 16:20 |
raoul | right right, I've somewhat started work on that as part of my #870 stuff, trawling through the test failures atm | 16:21 |
gitlab-br-bot | Issue #870: Root cache directory https://gitlab.com/BuildStream/buildstream/issues/870 | 16:21 |
tlater[m] | Well, was to be expected, I suppose. Damn, would have been nice if we could just change a few lines. | 16:21 |
tlater[m] | In any case, thanks for looking at it :) | 16:22 |
raoul | if only :P | 16:22 |
raoul | nw :) | 16:22 |
*** nimish has quit IRC | 16:29 | |
*** nimish has joined #buildstream | 16:29 | |
gitlab-br-bot | tristanvb closed issue #868 (bzr plugin doesnt parallelize well) on buildstream https://gitlab.com/BuildStream/buildstream/issues/868 | 16:35 |
gitlab-br-bot | tristanvb merged MR !1083 (tristan/fix-bzr-race->master: Fix bzr race conditions) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1083 | 16:35 |
*** nimish has quit IRC | 16:44 | |
*** nimish has joined #buildstream | 16:45 | |
benschubert | The bug were BuildStream waited until it had fetched everything before building has been fixed on master already right? | 16:48 |
*** ChanServ sets mode: +o tristan | 16:51 | |
tristan | benschubert, Yes | 16:51 |
tristan | benschubert, I've been pondering the additional enhancement but I'm worried it could be a performance killer, and I'm not 100% certain of that change | 16:52 |
benschubert | tristan: ok perfect thanks! Do you ahve a branch for this potential improvement? | 16:53 |
tristan | I.e. I should be able to explain exactly why the order of element processing would be better, if we were to change the loop to (A) Skip all skippable elements and promote those through queues in one loop first... (B) Process queues in reverse order, harvesting jobs as much as resources permit | 16:53 |
tristan | I don't, it's a fairly simple change to make | 16:53 |
tristan | benschubert, I did write up a test case, but then sadly found that it passes anyway | 16:54 |
tristan | I think provoking the behavior to change will be tricky | 16:54 |
tristan | benschubert, However... there is something that I *am* certain about | 16:54 |
tristan | benschubert, and that is... the initial promotion of elements through queues would require a *full* iteration over the elements of each queue, and each element would need to be asked if it is skippable | 16:55 |
benschubert | tristan: we know if an element is skippable when we put it in the queue, correct? | 16:56 |
*** nimish has quit IRC | 16:56 | |
tristan | and then those lists would need to be queried *again*, that time asking each element if they are ready to process, but stopping as soon as we fill up the resources for that queue | 16:56 |
tristan | benschubert, An element can *become* skippable as a result of the completion of processing of some other element | 16:56 |
tristan | as the data model is linked | 16:56 |
tristan | I mean yes, we *initially* place elements directly on the skip queue | 16:57 |
*** nimish has joined #buildstream | 16:57 | |
benschubert | RIght, but if it was not skippable before, it meant it was waiting and not ready. Correct? That means, if we only add elements to a queue when they are _ready_, we would fix the problem and remove the need of querying the queue. And knowing when an element is ready for a queue, is a matter of updating reverse dependencies everytime we change. Or am I missing something? (I'm not saying this is simple to implement, just | 16:58 |
benschubert | conceptually) | 16:58 |
tristan | benschubert, In any case that would be pretty expensive... some background is that the original design was based on data which ... slightly changed | 16:58 |
tristan | I.e. we rely on sort order of elements to ensure that the iterations stay small enough | 16:59 |
tristan | we just "grab as much as we can" from the end of a queue and put it on another when it's done, and hope sort order makes that ready stuff always near the tip | 16:59 |
tristan | But now that we have this dynamic checking for pulling elements, that data has a bit of a different shape | 16:59 |
benschubert | tristan: I have a few idea on how to "fix" those problems, but that would require a huge refactoring and I'm not sure I understand the entire state transition/pipeline well enough. Would you be happy if we catch up at the gathering and try to design a plan to refactor the pipeline? :) | 17:00 |
benschubert | it might be easier in person | 17:00 |
tristan | benschubert, I'm not sure exactly what you mean about adding elements to a queue only when they are ready | 17:00 |
tristan | benschubert, the order needs to be preserved, first of all - so you dont improve things from splitting waiting and ready elements into separate lists | 17:01 |
tristan | You want the next ready element in the list, *at the time* a job has completed | 17:01 |
*** nimish has quit IRC | 17:01 | |
tristan | benschubert, Normally, the fact that a job completed means that something in waiting state becomes ready... but it can potentially *also* mean that something goes from waiting state to skipped state | 17:02 |
tristan | I suspect there is a case of that which revolves around discovering a strong artifact key of a pulled artifact in non strict mode | 17:02 |
benschubert | tristan: we currently rely on checking the status whenever a state change. This tells us what needs to happen (skip/buildable/etc). We do know exactly which events change a state and the state of reverse dependencies. We could therefore do without those waiting queues, and whenever an element is finished processing somewhere, we go through its reverse deps and update them accordingly (putting them in a queue when needed) | 17:02 |
tristan | benschubert, I'm not on the same page as you, but I am in a similar book | 17:03 |
benschubert | It might require thinking more thoroughly about those transition states, but that would remove lots of unneeded operations we are currently doing I think | 17:03 |
benschubert | tristan: :D where am I not explaining well enough? (I've been thinking about this for a while, so I'm not sure what is clear or not) | 17:04 |
tristan | benschubert, I.e. don't tangle the data model and the scheduler together - instead have the data model handle caching and cache invalidation itself | 17:04 |
*** nimish has joined #buildstream | 17:04 | |
tristan | benschubert, In this way, any question the scheduler asks the data model is only ever expensive when it needs to be | 17:05 |
tristan | normally any question is answered with a return self.__cached_something | 17:05 |
benschubert | tristan: I agree with that, I don't think we need the pipeline and the data model needs to be too tangled, if we rework what information the data model gives (like reverse dependencies) | 17:07 |
gitlab-br-bot | tlater opened (was WIP) MR !1031 (tlater/message-lines->master: Avoid "showing 0 lines" messages when we're asked to show no lines) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1031 | 17:07 |
*** nimish has quit IRC | 17:07 | |
benschubert | and by moving more restrictively on the datamodel we would be able to optimize the pipeline/scheduler a lot | 17:08 |
tlater[m] | Would someone mind giving this a final review? https://gitlab.com/BuildStream/buildstream/merge_requests/1031 | 17:08 |
gitlab-br-bot | aevri opened MR !1086 (aevri/bst_track_guidance->master: Fixup refs to 'bst track' and 'bst fetch') on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1086 | 17:09 |
benschubert | This would require a more or less complete rewrite of those pieces. and might require us to have more things in memory (and that is bad since we need to reduce our memory footprint) | 17:09 |
tristan | benschubert, honestly I am confident that Consistency interrogations are correctly cached and inexpensive, but I don't know that that is the case for yet-to-be-resolved cache keys | 17:09 |
benschubert | tristan: that is correct. However, no matter how inexpensive it is, when you have 50k elements and you reinterogate each waiting one when any element stage changes, this is not sustainable | 17:10 |
tristan | benschubert, Sure, but those are separate problems which belong in separate places - for now the scheduler uses queues and lists of elements | 17:10 |
tristan | that could change with a totally fancy expensive rewrite which processes graph data instead of lists for instance; but that operation would be isolated in the scheduler | 17:11 |
tristan | benschubert, essentially, I have little faith that the scheduler, as written, will perform acceptably by doing more interrogation in the loop under question, i.e. to get skip elements over the wall quicker | 17:12 |
tristan | benschubert, and I have little evidence that doing that will improve the outcome order significantly either | 17:12 |
tristan | I'm not currently considering an expensive scheduler rewrite either :) | 17:13 |
benschubert | tristan: ah! I got you. Agreed! | 17:13 |
tristan | but if that happens it's not a bad thing :) | 17:13 |
benschubert | tristan: Ok, I will try to have a rewrite plan for it for the gathering, might be simpler to discuss it in one of the performance sessions :) | 17:14 |
tristan | yeah that does sound interesting :) | 17:14 |
tristan | it's certainly a fun topic | 17:14 |
gitlab-br-bot | tristanvb opened MR !1087 (tristan/cas-cleanup-improve->master: _cas/cascache.py: Cleanup directories when removing refs) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1087 | 17:20 |
gitlab-br-bot | jennis opened MR !1088 (jennis/add_new_profile_topic->master: Add new 'scheduler' and 'load-selection' profiling topics) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1088 | 17:23 |
gitlab-br-bot | tlater closed issue #281 (Make the testutils API public) on buildstream https://gitlab.com/BuildStream/buildstream/issues/281 | 17:37 |
tristan | juergbi, any problem with cleaning up the directory entries when doing CASCache.remove() ? | 17:46 |
tristan | maybe there is a reason we weren't doing that already ? | 17:46 |
*** nimish has joined #buildstream | 17:46 | |
tristan | !1087 cleans it up and adds a regression test for it | 17:46 |
tristan | Also wondering what's with the files I have in ~/.cache/buildstream/artifacts/tmp | 17:47 |
tristan | Maybe that is residue from an older version ? | 17:47 |
*** tristan has quit IRC | 17:49 | |
* tlater[m] wonders if we can blanket skip integration tests when not on Linux+Bwrap | 18:04 | |
tlater[m] | Seems kinda odd that we'd need to add that mark to every integration test. | 18:04 |
*** nimish has quit IRC | 18:04 | |
*** raoul has quit IRC | 18:05 | |
*** jonathanmaw has quit IRC | 18:06 | |
*** nimish has joined #buildstream | 18:06 | |
*** tristan has joined #buildstream | 18:09 | |
*** nimish has quit IRC | 18:14 | |
*** ChanServ sets mode: +o tristan | 18:16 | |
tristan | jjardon, So BuildStream master makes about ~90G with freedesktop-sdk(18.08) all.bst | 18:16 |
tristan | Have a fresh build and know that cleanups have removed anything not in my build | 18:17 |
tristan | That will be the expensive cached builddirs | 18:18 |
*** kapil___ has quit IRC | 18:44 | |
*** toscalix has quit IRC | 18:47 | |
gitlab-br-bot | aevri merged MR !1078 (aevri/shell_separator_hint->master: cli.py: add a hint about '--' to 'bst shell' help) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1078 | 18:56 |
*** nimish has joined #buildstream | 19:17 | |
*** nimish has joined #buildstream | 19:17 | |
jjardon | tristan: in the positive side; good test case? :) | 19:30 |
tristan | jjardon, Yeah looks like gnome-build-meta isn't building out of the box for me :-/ | 19:37 |
jjardon | Mmm, try gnome-3.30 branch; that one should build as is building spacious sha, not master | 19:42 |
tristan | I see | 19:43 |
tristan | I will give it a shot | 19:43 |
*** nimish has quit IRC | 19:44 | |
alatiera | tristan: is it currently possible to point bst to a project.refs in a remote location? | 19:47 |
alatiera | tristan: like another git repo, or hosted in a server | 19:47 |
alatiera | we were thinking the other day how to make gnome-build-meta always build while still closely tracking master | 19:48 |
tristan | jjardon, btw, that's what I get with master: https://bpaste.net/show/0e01d683030f | 19:48 |
tristan | but doesnt gnome-build-meta inherit the strip binaries stuff from freedesktop-sdk ? | 19:49 |
alatiera | one idea was that after each successful build in the master branch we push the project.refs file somewhere | 19:49 |
alatiera | but then for local development we would need to add extra instruction or a wrapper to fetch the file | 19:49 |
*** tristan has quit IRC | 19:52 | |
*** tristan has joined #buildstream | 19:56 | |
*** lachlan has quit IRC | 20:09 | |
gitlab-br-bot | tristanvb merged MR !1087 (tristan/cas-cleanup-improve->master: CASCache cleanup improvements) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1087 | 20:57 |
gitlab-br-bot | cs-shadow opened MR !1089 (chandan/import-is-not-buildelement->master: Derive import plugin from Element instead of BuildElement) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1089 | 21:25 |
gitlab-br-bot | tristanvb opened MR !1090 (tristan/fix-pip-source-test->master: tests/testutils/python_repo.py: Use subprocess to run sdist) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1090 | 21:28 |
cs-shadow | tristan: mind having a look at !1089 ^^ when you get a chance? | 21:29 |
cs-shadow | It's a small change but I'd like to make sure I am not missing some subtle details here :) | 21:29 |
*** alatiera has quit IRC | 21:32 | |
*** ChanServ sets mode: +o tristan | 21:33 | |
tristan | cs-shadow, I already did ! | 21:33 |
tristan | cs-shadow, nice spot | 21:33 |
cs-shadow | tristan: thanks! | 21:34 |
tristan | cs-shadow, if you've been seeing the same thing in CI as me, will be good to get this through first: https://gitlab.com/BuildStream/buildstream/merge_requests/1090 | 21:34 |
* tristan has been playing whack a mole with that spurious pip test failure | 21:35 | |
cs-shadow | tristan: sure, I've cancelled my automatic merge. Will wait for !1090 to go through first | 21:36 |
cs-shadow | I did see that issue at least once but I chalked it up it as a random failure but it's great that you are looking into it | 21:37 |
gitlab-br-bot | cs-shadow approved MR !1090 (tristan/fix-pip-source-test->master: tests/testutils/python_repo.py: Use subprocess to run sdist) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1090 | 21:39 |
tristan | cs-shadow, I think thats the last spurious failure :) | 21:39 |
tristan | I fixed another one yesterday | 21:39 |
tristan | and both were more-or-less explainable, which is good | 21:39 |
tristan | today's was a bit cryptic, but we can see the general area where things are going wrong and just avoid it | 21:40 |
* tristan gotta change location | 21:40 | |
cs-shadow | haha, as they say only thing bad than no tests is a flaky test | 21:41 |
cs-shadow | so many thanks for fixing them all | 21:42 |
*** tristan has quit IRC | 21:43 | |
*** benschubert has quit IRC | 21:57 | |
*** bochecha has quit IRC | 21:58 | |
gitlab-br-bot | tristanvb merged MR !1090 (tristan/fix-pip-source-test->master: tests/testutils/python_repo.py: Use subprocess to run sdist) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1090 | 22:07 |
*** tristan has joined #buildstream | 22:10 | |
gitlab-br-bot | cs-shadow merged MR !1089 (chandan/import-is-not-buildelement->master: Derive import plugin from Element instead of BuildElement) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1089 | 22:46 |
gitlab-br-bot | tristanvb closed issue #779 (It should be possible to disable error and message lines completely) on buildstream https://gitlab.com/BuildStream/buildstream/issues/779 | 23:23 |
gitlab-br-bot | tristanvb merged MR !1031 (tlater/message-lines->master: Avoid "showing 0 lines" messages when we're asked to show no lines) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1031 | 23:23 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!