*** mohan43u has quit IRC | 02:04 | |
*** mohan43u has joined #buildstream | 02:07 | |
*** mohan43u has quit IRC | 05:04 | |
*** mohan43u has joined #buildstream | 05:08 | |
*** tristan has joined #buildstream | 05:54 | |
*** Prince781 has quit IRC | 05:58 | |
*** tristan has quit IRC | 06:39 | |
*** tristan has joined #buildstream | 06:44 | |
*** toscalix has joined #buildstream | 08:12 | |
*** mohan43u has quit IRC | 09:04 | |
*** mohan43u has joined #buildstream | 09:08 | |
*** solid_black has joined #buildstream | 10:32 | |
*** slaf has quit IRC | 10:52 | |
*** slaf has joined #buildstream | 10:55 | |
*** mohan43u has quit IRC | 11:05 | |
*** mohan43u has joined #buildstream | 11:08 | |
*** solid_black has quit IRC | 11:12 | |
*** solid_black_ has joined #buildstream | 11:14 | |
*** solid_black has joined #buildstream | 12:27 | |
*** solid_black_ has quit IRC | 12:28 | |
*** solid_black_ has joined #buildstream | 12:35 | |
*** solid_black has quit IRC | 12:35 | |
*** solid_black_ is now known as solid_black | 12:37 | |
tristan | juergbi, We have a mix of strict mode policy effective within a single pipeline | 13:22 |
---|---|---|
tristan | This appears to be my fault | 13:22 |
tristan | I wonder if this can be correct in any possibly universe, if not, I mean to correct the error | 13:23 |
juergbi | not sure right now | 13:28 |
tristan | Ok, what I did, and it "looks" like I fucked up while doing it... is make the user configuration declare strict mode preference on a per project basis | 13:30 |
tristan | This is certainly correct and a good thing | 13:30 |
tristan | The problem is Context.get_strict() takes a project name, instead of always using the toplevel project | 13:30 |
tristan | meaning when we have junctions in play, we use different strict mode settings for different elements inside the same pipeline | 13:30 |
tristan | If this is intentional, I will not change it, but it looks quite error prone and incorrect | 13:31 |
tristan | juergbi, dont worry, I dont expect any answer right now... it's late here already, and I have a note about it so I will remind you this week :D | 13:31 |
tristan | fwiw, I've landed a bunch of stuff in the last couple days, closed two bugs, refactored a bit, and threw away ~80 LOC in the process | 13:32 |
*** solid_black has quit IRC | 13:41 | |
* paulsherwood is asked elswhere "is there any plan for bi/analytics for buildstream" | 13:59 | |
tristan | Ummm, a quick google search shows me that that is either something I should never really understand, or something that could be translated into terminology that makes sense to me :) | 14:01 |
tristan | "Business Intelligence" ? | 14:01 |
tristan | sounds like sales-speak :) | 14:01 |
* tristan has to leave closing coffee shop... | 14:02 | |
paulsherwood | :) | 14:03 |
paulsherwood | i think it means (in this context) getting buildstream to generate statistics over time | 14:05 |
*** tristan has quit IRC | 14:05 | |
paulsherwood | (for example i've been frabbing ybd release-note functionality to generate repo stats as it goes) | 14:06 |
*** tristan has joined #buildstream | 14:09 | |
tristan | paulsherwood, got your reply from the logger... and going to get some take out dinner and shut down the brain... | 14:10 |
tristan | paulsherwood, at first sight, I think that should be out of scope - rather, we should be open to providing machine readable logging (as we are attempting for benchmarking purposes), such that other automated systems can easily use that | 14:11 |
tristan | as buildstream is not an on-going process; it seems that for ongoing collection of statistical data, that should be another component, integrated in CI or such | 14:12 |
tristan | gitlab does *some* minimal amount of that in terms of merge requests and CI statistics (for a project configured to run BuildStream in CI) | 14:13 |
tristan | probably more particular "stuff" (beyond "how many builds passed"), could be scraped with a bst logging aware CI runner/system, or by collecting artifacts from gitlab CI to view machine readable logs and do some number crunching | 14:15 |
tristan | I suppose the first question one has to ask is "What kind of particular statistic do you want to see out of builds", and move forward from there | 14:15 |
tristan | "How often are you failing to download source code from a third party server" might be interesting, for instance | 14:16 |
paulsherwood | the two areas that i know are interesting are both time-series... | 14:28 |
paulsherwood | 1) how long a given pipeline takes (and same for each of its component steps), so we can spot when something starts taking more time | 14:29 |
paulsherwood | 2) how much code change/churn in total and for each component | 14:29 |
jmac | 1) Is part of the performance analysis plan | 14:39 |
tristan | 2) could probably be done using workspace features and comparing between builds, if you are already in a position where you have branches being tracked and CI being run | 14:46 |
tristan | i.e. once you have a strategy for how you continuously build something, you could pretty easily get those statistics based on the builds you've decided to run | 14:46 |
tristan | for added pleasure, you might get diffs of the resulting artifacts and get some ratio on how much that code churn effected the build results, too | 14:48 |
jmac | Interesting idea | 14:56 |
*** solid_black has joined #buildstream | 15:31 | |
*** solid_black has quit IRC | 15:37 | |
*** toscalix has quit IRC | 15:44 | |
*** mohan43u has quit IRC | 16:05 | |
*** mohan43u has joined #buildstream | 16:08 | |
*** valentind has joined #buildstream | 19:18 | |
*** valentind has quit IRC | 19:49 | |
*** valentind has joined #buildstream | 19:49 | |
*** valentind has quit IRC | 20:02 | |
*** mohan43u has quit IRC | 20:04 | |
*** valentind has joined #buildstream | 20:07 | |
*** mohan43u has joined #buildstream | 20:08 | |
*** tristan has quit IRC | 20:55 | |
*** mohan43u has quit IRC | 21:05 | |
*** mohan43u has joined #buildstream | 21:08 | |
*** xjuan has joined #buildstream | 21:52 | |
*** xjuan has quit IRC | 22:40 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!