IRC logs for #baserock for Tuesday, 2017-02-21

*** toscalix has quit IRC02:09
*** gtristan has quit IRC06:06
*** gtristan has joined #baserock06:39
*** jude_ has joined #baserock08:22
*** ctbruce has joined #baserock08:38
*** noisecell has joined #baserock08:45
*** paulwaters_ has joined #baserock08:59
*** rdale has joined #baserock08:59
*** jonathanmaw has joined #baserock09:00
paulsherwoodgtristan: i'm struggling with this https://gitlab.com/baserock/ybd/merge_requests/31009:29
paulsherwoodiiuc you have a situation where you are autogenerating sha: fields, bevause you want to preserve ref: fields as (say) branches?09:30
gtristanThe idea is that ref can be used as a branch now09:31
gtristanThat branch is useful as metadata for updating the sha09:31
paulsherwoodright. but it was always possible to do that, using unpetrify-ref09:32
paulsherwood(unless i'm missing something)09:32
gtristanBut we want to preserve the model that "A commit of definitions represents an exact build"09:32
gtristanI.e. if the sha exists, YBD should build it, because that state of definitions represents something exact09:32
gtristanpaulsherwood, unpetrify-ref has never been a reliable branch, though09:33
gtristanHowever, if we discard the concept of 'sha' entirely, and use unpetrify-ref to hold branches, and 'ref' to hold only commit shas, that would indeed mean less fields09:33
paulsherwoodright... so imagine if we had started with different names for this: 'ref:' would have been 'sha:', and 'unpetrify-ref:' would have been 'ref:' i think09:33
gtristanindeed09:34
paulsherwoodin which case... i think the functionality you are seeking may be already supported... with 'track-branches'09:35
gtristanWell, it's important in our case that it is _not_ YBD which updates the sha09:35
gtristanAnd, ybd itself is not really capable of rewriting definitions.09:36
paulsherwoodi'm not suggesting it does09:36
gtristantrack-branches updates sha from ref does it not ?09:36
paulsherwoodno09:36
gtristanor it makes assumptions about unpetrify-ref09:36
gtristanOk... hmmm09:36
gtristanlet me dig deeper and see, are you sure it satisfies this ?09:37
paulsherwoodtrack-branches assumes that you want to resolve from unpetrify-ref09:37
paulsherwoodno i'm not sure, hence i'm asking here09:37
paulsherwoodso... if (your) tooling writes ref: with actual shas, and track-branches: is not set, ybd will build your shas...09:38
paulsherwoodif track-branches: is set, ybd will build from unpetrify-ref09:38
gtristanThat can work09:38
gtristanSo we would not use track-branches at all09:38
paulsherwoodnot for reproducible builds, no09:39
gtristanBut we would have to store all branches in unpetrify-ref, and _make sure_ that there are no dangling unpetrify-refs in the project09:39
paulsherwoodbut for tracking a brancy, yes you would :)09:39
paulsherwoodcorrect09:39
paulsherwoodit's easy enough to validate unpetrify-ref: exists09:39
gtristanSo its just a matter of having someone delay the project another day or week, ensuring that definitions has clean unpetrify-refs in that project09:40
gtristan:-/09:40
gtristanbut you are correct that its unneeded with that approach09:40
gtristanand cleaner09:40
gtristanpaulsherwood, there is also the problem of unpetrify-ref specifying a _valid_ branch which we do not intend to track09:40
gtristanso it cant really be automated09:40
paulsherwoodwell, cleanest would be names that actually mean what they say :)09:41
gtristanbut we could nuke them all09:41
paulsherwoodgtristan: track-branches: can be true, or a set of components09:41
gtristanHowever I dont want that functionality09:41
gtristantrack-branches in this pipeline situation must always be False09:42
gtristanit's a separate tool which rewrites definitions and does the tracking09:42
gtristanbased on the branches it reads from the convenient export target.yml gives us09:42
paulsherwoodah, ok09:42
paulsherwoodwell, put it this way... i'm ok to merge 310, but we're just sticking more gunk on top of gunk09:43
gtristanit's important that it happens there too, because then the latest commits for those branches match the repo data we've parsed to update build instructions and rpm deployment data from09:43
gtristanUnderstood09:43
gtristanLet me think on it another 30 min and see if we can easily reverse this09:43
paulsherwoodsuer09:44
gtristanTo be honest I'm a bit reluctant to pay too much attention to ybd long term, seeing as *cough* buildstream automatic conversion of definitions almost builds gnome.bst completely :-/09:45
paulsherwoodthat's why i'm ok to merge :)09:46
paulsherwoodi just wanted to make sure we both understand the usecases...09:46
paulsherwoodotherwise we'll be having this conversation in revers about buildstream later09:46
gtristanYes :)09:46
*** ssam2 has joined #baserock10:09
*** ChanServ sets mode: +v ssam210:09
*** leeming has quit IRC10:42
*** tiagogomes has quit IRC10:42
*** jonathanmaw has quit IRC10:42
*** ctbruce has quit IRC10:42
*** Guest43993 has quit IRC10:43
*** ssam2 has quit IRC10:43
*** CTtpollard has quit IRC10:43
*** locallycompact has joined #baserock10:54
*** ctbruce has joined #baserock10:54
*** ssam2 has joined #baserock10:54
*** ChanServ sets mode: +v ssam210:54
*** tiagogomes has joined #baserock10:55
*** jonathanmaw has joined #baserock10:55
*** CTtpollard has joined #baserock10:55
*** leeming has joined #baserock10:55
*** Guest43993 has joined #baserock10:55
*** paulwaters_ has joined #baserock10:55
*** CTtpollard has quit IRC10:56
*** CTtpollard has joined #baserock10:59
*** jude_ has quit IRC11:07
*** jude_ has joined #baserock11:12
*** CTtpollard has quit IRC11:27
*** CTtpollard has joined #baserock11:31
*** leeming has quit IRC11:33
*** leeming has joined #baserock11:33
*** fay has joined #baserock13:30
*** fay is now known as Guest5852713:31
*** Guest43993 has quit IRC13:34
*** toscalix has joined #baserock14:34
*** toscalix has quit IRC14:42
*** toscalix has joined #baserock14:45
*** toscalix has quit IRC14:52
*** gtristan has quit IRC15:00
*** noisecell has quit IRC15:28
*** noisecell has joined #baserock15:28
*** gtristan has joined #baserock15:30
*** toscalix has joined #baserock15:49
*** toscalix has quit IRC15:55
*** noisecell has quit IRC16:06
*** toscalix has joined #baserock16:08
*** toscalix has quit IRC16:11
*** toscalix has joined #baserock16:14
*** toscalix has quit IRC16:15
*** toscalix has joined #baserock16:18
*** toscalix has quit IRC16:23
*** ctbruce has quit IRC16:24
*** Guest58527 has quit IRC16:29
*** toscalix has joined #baserock16:38
*** CTtpollard has quit IRC16:40
*** toscalix has quit IRC16:45
*** CTtpollard has joined #baserock16:55
*** jonathanmaw has quit IRC17:36
*** jude_ has quit IRC17:56
*** toscalix has joined #baserock18:10
*** locallycompact has quit IRC18:13
*** ssam2 has quit IRC18:25
*** toscalix has quit IRC19:16
*** rdale has quit IRC19:36
*** jude_ has joined #baserock19:41
*** toscalix has joined #baserock20:36
*** locallycompact has joined #baserock21:07
*** toscalix has quit IRC21:28
*** jude_ has quit IRC22:43
*** locallycompact has quit IRC23:24

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