*** persia has quit IRC | 01:21 | |
*** persia has joined #baserock | 01:22 | |
*** gtristan has quit IRC | 06:57 | |
*** jude_ has joined #baserock | 06:58 | |
*** gtristan has joined #baserock | 07:25 | |
*** jonathanmaw has joined #baserock | 08:34 | |
*** ssam2 has joined #baserock | 09:18 | |
*** ChanServ sets mode: +v ssam2 | 09:18 | |
ssam2 | yess!!!!!!!!! | 09:18 |
---|---|---|
ssam2 | https://gitlab.com/baserock/definitions/pipelines/13144466 | 09:18 |
benbrown_ | \o/ | 09:18 |
ssam2 | well done to all involved in this marathon | 09:19 |
ironfoot | wow, that's soo green | 09:19 |
* benbrown_ wonders whether he should rebase out the reverts, of if we should just deal with those during a manual merge | 09:20 | |
benbrown_ | s/of/or/ | 09:20 |
ssam2 | if you're up for doing a rebase, then yeah | 09:20 |
ssam2 | well, or we could cherry pick bits | 09:21 |
ssam2 | i'm happy either way | 09:21 |
gitlab-br-bot | definitions: merge request (benbrown/sam/fix-ci->master: Fix caching in CI and some other optimizations) #63 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/63 | 09:27 |
ssam2 | let's see how fast a no-op rebuild is now | 09:28 |
benbrown_ | gitlab-br-bot: oh, welcome back | 09:30 |
gtristan | ssam2, nice :) | 09:30 |
*** locallycompact has joined #baserock | 09:44 | |
benbrown_ | https://gitlab.com/baserock/definitions/-/jobs/37567134 "Unknown exception in SIGCHLD handler" is an interesting error | 11:00 |
benbrown_ | the pipeline seems to be continuing though | 11:00 |
benbrown_ | Also seeing a few "Unknown child process pid 2449, will report returncode 255" | 11:01 |
ssam2 | yes, those might be interesting to tlater | 11:02 |
ssam2 | were he here :-) | 11:02 |
ssam2 | he's done quite a bit on buildstream job control recently | 11:03 |
ssam2 | apparently there's a fix waiting to be merged for that | 11:05 |
benbrown_ | oh, cool | 11:05 |
ssam2 | i noticed that the 'build-or-show' script I wrote for the CI doesn't actually work as intended | 11:19 |
ssam2 | the idea is that if the element to be built is shown as 'downloadable', we skip running `bst build` to avoid spending ages pulling GBs of stuff from ostree.baserock.org | 11:20 |
ssam2 | but the target elements are all stacks, and those don't get pushed to the remote cache | 11:20 |
ssam2 | i guess a reasonable fix would be to generate compose elements for each one | 11:20 |
ssam2 | which we'd want to do anyway if we were actually using these systems for anything other than testing BuildStream | 11:21 |
gtristan | ssam2, stack elements dont get pushed to remote caches ?? | 11:26 |
gtristan | ssam2, you sure ? I think they contain metadata and are still valid artifacts | 11:27 |
ssam2 | i'm sure that when i `bst show` a stack that was previously built, it says 'waiting' not 'downloadable' | 11:27 |
ssam2 | maybe it's in the cache, but there's another issue... let's check | 11:28 |
ssam2 | https://ostree.baserock.org/cache/refs/heads/baserock/ doesn't contain any refs with 'systems' in their name | 11:28 |
ssam2 | and e.g. in this build log ... https://gitlab.com/baserock/definitions/-/jobs/37567133 | 11:29 |
ssam2 | there's no 'push:systems/base-system-content.bst' task | 11:29 |
gtristan | ssam2, if that is confirmed, I would say it's a bug | 11:29 |
ssam2 | ok, i'll dig a bit deeper and make a bug report | 11:30 |
gtristan | ssam2, it should be very cheap to push them back and forth, and they contain valuable stuff (like the integration commands) | 11:30 |
gtristan | weird though, I dont see why we would skip them, we would have to have special cases in buildstream saying "dont upload this cause it's a stack" | 11:31 |
ssam2 | yeah | 11:31 |
ssam2 | possibly more a bug triggered by the fact that stacks are empty | 11:32 |
gtristan | mmm | 11:39 |
gtristan | Ok, perhaps fallout from when we changed the structure to allow for metadata & logs in separate directories | 11:39 |
ssam2 | seems there might be another buildstream bug at play | 12:38 |
ssam2 | https://gitlab.com/baserock/definitions/-/jobs/37475223 is an incomplete but successful build of ivi-system-content.bst | 12:38 |
ssam2 | hmm, i wonder if this is related to the other issue -- perhaps it always ends the pipeline early, but normally only 1 element early? | 12:39 |
gtristan | ssam2, I think we normally do CI with `--on-error continue` to ensure we see all the errors at once, maybe we're just failing to report non-zero exit status in that case ? | 12:43 |
ssam2 | we're not passing `--on-error continue` | 12:50 |
ssam2 | and there's no error; on rerun the job is building fine: https://gitlab.com/baserock/definitions/-/jobs/37567137 | 12:51 |
ssam2 | has just built, in fact | 12:51 |
ssam2 | but all that building should have been done as part of the previous job; the definitions are identical for both | 12:52 |
ssam2 | could someone approve https://gitlab.com/baserock/definitions/merge_requests/63/ (fix CI) so we can merge ? | 13:29 |
gitlab-br-bot | definitions: merge request (benbrown/sam/fix-ci->master: Fix caching in CI and some other optimizations) #63 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/63 | 13:30 |
gitlab-br-bot | definitions: merge request (benbrown/sam/fix-ci->master: Fix caching in CI and some other optimizations) #63 changed state ("merged"): https://gitlab.com/baserock/definitions/merge_requests/63 | 13:31 |
ssam2 | thanks! | 13:32 |
benbrown_ | \o/ | 13:32 |
ssam2 | ok, so we're almost back to where we were a month ago when i decided to try and fix the ci to speed up the process of merging the outstanding branches... which seems to have only caused delays :-) | 13:33 |
ssam2 | but, the gitlab CI cache seems to be working reasonably reliably, even if it still takes 10 minutes to get all the sources in place for each job | 13:34 |
benbrown_ | ssam2: !59 first? | 13:35 |
ssam2 | yeah that's the next one. i'll rebase it and see what happens | 13:35 |
benbrown_ | cool | 13:35 |
gitlab-br-bot | definitions: merge request (sam/armv8-ppc64->master: Various fixes for armv8 and ppc64) #59 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/59 | 13:45 |
jjardon | nice | 13:48 |
jjardon | I think is time to depend in a specific version of ybd/spec/def2spec instead current master of everything | 13:49 |
jjardon | we used to use latest buildstream, what are we using now? ssam2 do you know? | 13:49 |
* jjardon prepares a branch | 13:59 | |
ssam2 | we use latest version of buildstream | 14:00 |
ssam2 | we should continue to do that for now... at least until buildstream 1.0 | 14:00 |
jjardon | no for master of definitions please; we can not know when the things get broken if not. We can still run the CI periodically with master of everything if you want | 14:04 |
ssam2 | I still consider the buildstream conversions experimental | 14:06 |
ssam2 | buildstream 1.0 would be a good time to try and declare them stable | 14:07 |
jjardon | rigth, another reason to not use master of the conversion script or buildstream; build can brake at any point, doesnt matter master of definitions has built before | 14:13 |
jjardon | you are still completely free to experiment in branches or even in periodic jobs | 14:13 |
ssam2 | sure, i just feel like there's already a load of stuff outstanding | 14:14 |
gitlab-br-bot | definitions: merge request (jjardon/no_master2->master: Do not use master of our build tools, but a specific version instead) #64 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/64 | 14:15 |
gitlab-br-bot | definitions: merge request (jjardon/no_master2->master: WIP: Do not use master of our build tools, but a specific version instead) #64 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/64 | 14:15 |
gitlab-br-bot | definitions: merge request (jjardon/no_master2->master: WIP: Do not use master of our build tools, but a specific version instead) #64 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/64 | 14:19 |
gitlab-br-bot | definitions: merge request (jjardon/no_master2->master: WIP: Do not use master of our build tools, but a specific version instead) #64 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/64 | 14:21 |
gitlab-br-bot | definitions: merge request (jjardon/no_master2->master: Do not use master of our build tools, but a specific version instead) #64 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/64 | 14:26 |
*** gtristan has quit IRC | 14:46 | |
benbrown_ | jjardon: you have comments | 14:52 |
*** gtristan has joined #baserock | 15:02 | |
gitlab-br-bot | definitions: merge request (jjardon/no_master2->master: Do not use master of our build tools, but a specific version instead) #64 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/64 | 15:23 |
gitlab-br-bot | definitions: merge request (jjardon/no_master2->master: Do not use master of our build tools, but a specific version instead) #64 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/64 | 15:26 |
gitlab-br-bot | definitions: merge request (jjardon/no_master2->master: Do not use master of our build tools, but a specific version instead) #64 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/64 | 15:27 |
gitlab-br-bot | definitions: merge request (jjardon/no_master2->master: Do not use master of our build tools, but a specific version instead) #64 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/64 | 15:28 |
gitlab-br-bot | definitions: merge request (jjardon/no_master2->master: Do not use master of our build tools, but a specific version instead) #64 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/64 | 15:29 |
gitlab-br-bot | definitions: merge request (jjardon/no_master2->master: Do not use master of our build tools, but a specific version instead) #64 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/64 | 15:29 |
gitlab-br-bot | definitions: merge request (jjardon/no_master2->master: Do not use master of our build tools, but a specific version instead) #64 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/64 | 15:30 |
gitlab-br-bot | definitions: merge request (jjardon/no_master2->master: Do not use master of our build tools, but a specific version instead) #64 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/64 | 15:32 |
gitlab-br-bot | definitions: merge request (jjardon/no_master2->master: Do not use master of our build tools, but a specific version instead) #64 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/64 | 15:33 |
jjardon | ssam2: I think the solution descibed at https://gitlab.com/baserock/definitions/merge_requests/64 will be good enough: we use stable versions of the tools in master of definitions, so CI never breaks. But we still run every day the full CI with master of buildstream and defs2bst, so we can check we are not breaking anything | 15:36 |
ssam2 | sounds good, apart from there isn't a stable version of defs2bst or buildstream yet :-) | 15:37 |
ssam2 | but we can work with it | 15:37 |
*** adds68 has quit IRC | 16:01 | |
*** jonathanmaw has quit IRC | 16:31 | |
*** ssam2 has quit IRC | 16:38 | |
*** locallycompact has quit IRC | 17:12 | |
*** jude_ has quit IRC | 17:21 | |
*** locallycompact has joined #baserock | 19:55 | |
*** locallycompact has quit IRC | 20:44 | |
*** adds68 has joined #baserock | 22:34 | |
*** adds68 has quit IRC | 23:01 | |
*** adds68 has joined #baserock | 23:10 | |
*** adds68 has quit IRC | 23:16 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!