*** toscalix has quit IRC | 02:09 | |
*** gtristan has quit IRC | 06:06 | |
*** gtristan has joined #baserock | 06:39 | |
*** jude_ has joined #baserock | 08:22 | |
*** ctbruce has joined #baserock | 08:38 | |
*** noisecell has joined #baserock | 08:45 | |
*** paulwaters_ has joined #baserock | 08:59 | |
*** rdale has joined #baserock | 08:59 | |
*** jonathanmaw has joined #baserock | 09:00 | |
paulsherwood | gtristan: i'm struggling with this https://gitlab.com/baserock/ybd/merge_requests/310 | 09:29 |
---|---|---|
paulsherwood | iiuc you have a situation where you are autogenerating sha: fields, bevause you want to preserve ref: fields as (say) branches? | 09:30 |
gtristan | The idea is that ref can be used as a branch now | 09:31 |
gtristan | That branch is useful as metadata for updating the sha | 09:31 |
paulsherwood | right. but it was always possible to do that, using unpetrify-ref | 09:32 |
paulsherwood | (unless i'm missing something) | 09:32 |
gtristan | But we want to preserve the model that "A commit of definitions represents an exact build" | 09:32 |
gtristan | I.e. if the sha exists, YBD should build it, because that state of definitions represents something exact | 09:32 |
gtristan | paulsherwood, unpetrify-ref has never been a reliable branch, though | 09:33 |
gtristan | However, 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 fields | 09:33 |
paulsherwood | right... so imagine if we had started with different names for this: 'ref:' would have been 'sha:', and 'unpetrify-ref:' would have been 'ref:' i think | 09:33 |
gtristan | indeed | 09:34 |
paulsherwood | in which case... i think the functionality you are seeking may be already supported... with 'track-branches' | 09:35 |
gtristan | Well, it's important in our case that it is _not_ YBD which updates the sha | 09:35 |
gtristan | And, ybd itself is not really capable of rewriting definitions. | 09:36 |
paulsherwood | i'm not suggesting it does | 09:36 |
gtristan | track-branches updates sha from ref does it not ? | 09:36 |
paulsherwood | no | 09:36 |
gtristan | or it makes assumptions about unpetrify-ref | 09:36 |
gtristan | Ok... hmmm | 09:36 |
gtristan | let me dig deeper and see, are you sure it satisfies this ? | 09:37 |
paulsherwood | track-branches assumes that you want to resolve from unpetrify-ref | 09:37 |
paulsherwood | no i'm not sure, hence i'm asking here | 09:37 |
paulsherwood | so... if (your) tooling writes ref: with actual shas, and track-branches: is not set, ybd will build your shas... | 09:38 |
paulsherwood | if track-branches: is set, ybd will build from unpetrify-ref | 09:38 |
gtristan | That can work | 09:38 |
gtristan | So we would not use track-branches at all | 09:38 |
paulsherwood | not for reproducible builds, no | 09:39 |
gtristan | But we would have to store all branches in unpetrify-ref, and _make sure_ that there are no dangling unpetrify-refs in the project | 09:39 |
paulsherwood | but for tracking a brancy, yes you would :) | 09:39 |
paulsherwood | correct | 09:39 |
paulsherwood | it's easy enough to validate unpetrify-ref: exists | 09:39 |
gtristan | So its just a matter of having someone delay the project another day or week, ensuring that definitions has clean unpetrify-refs in that project | 09:40 |
gtristan | :-/ | 09:40 |
gtristan | but you are correct that its unneeded with that approach | 09:40 |
gtristan | and cleaner | 09:40 |
gtristan | paulsherwood, there is also the problem of unpetrify-ref specifying a _valid_ branch which we do not intend to track | 09:40 |
gtristan | so it cant really be automated | 09:40 |
paulsherwood | well, cleanest would be names that actually mean what they say :) | 09:41 |
gtristan | but we could nuke them all | 09:41 |
paulsherwood | gtristan: track-branches: can be true, or a set of components | 09:41 |
gtristan | However I dont want that functionality | 09:41 |
gtristan | track-branches in this pipeline situation must always be False | 09:42 |
gtristan | it's a separate tool which rewrites definitions and does the tracking | 09:42 |
gtristan | based on the branches it reads from the convenient export target.yml gives us | 09:42 |
paulsherwood | ah, ok | 09:42 |
paulsherwood | well, put it this way... i'm ok to merge 310, but we're just sticking more gunk on top of gunk | 09:43 |
gtristan | it'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 from | 09:43 |
gtristan | Understood | 09:43 |
gtristan | Let me think on it another 30 min and see if we can easily reverse this | 09:43 |
paulsherwood | suer | 09:44 |
gtristan | To 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 |
paulsherwood | that's why i'm ok to merge :) | 09:46 |
paulsherwood | i just wanted to make sure we both understand the usecases... | 09:46 |
paulsherwood | otherwise we'll be having this conversation in revers about buildstream later | 09:46 |
gtristan | Yes :) | 09:46 |
*** ssam2 has joined #baserock | 10:09 | |
*** ChanServ sets mode: +v ssam2 | 10:09 | |
*** leeming has quit IRC | 10:42 | |
*** tiagogomes has quit IRC | 10:42 | |
*** jonathanmaw has quit IRC | 10:42 | |
*** ctbruce has quit IRC | 10:42 | |
*** Guest43993 has quit IRC | 10:43 | |
*** ssam2 has quit IRC | 10:43 | |
*** CTtpollard has quit IRC | 10:43 | |
*** locallycompact has joined #baserock | 10:54 | |
*** ctbruce has joined #baserock | 10:54 | |
*** ssam2 has joined #baserock | 10:54 | |
*** ChanServ sets mode: +v ssam2 | 10:54 | |
*** tiagogomes has joined #baserock | 10:55 | |
*** jonathanmaw has joined #baserock | 10:55 | |
*** CTtpollard has joined #baserock | 10:55 | |
*** leeming has joined #baserock | 10:55 | |
*** Guest43993 has joined #baserock | 10:55 | |
*** paulwaters_ has joined #baserock | 10:55 | |
*** CTtpollard has quit IRC | 10:56 | |
*** CTtpollard has joined #baserock | 10:59 | |
*** jude_ has quit IRC | 11:07 | |
*** jude_ has joined #baserock | 11:12 | |
*** CTtpollard has quit IRC | 11:27 | |
*** CTtpollard has joined #baserock | 11:31 | |
*** leeming has quit IRC | 11:33 | |
*** leeming has joined #baserock | 11:33 | |
*** fay has joined #baserock | 13:30 | |
*** fay is now known as Guest58527 | 13:31 | |
*** Guest43993 has quit IRC | 13:34 | |
*** toscalix has joined #baserock | 14:34 | |
*** toscalix has quit IRC | 14:42 | |
*** toscalix has joined #baserock | 14:45 | |
*** toscalix has quit IRC | 14:52 | |
*** gtristan has quit IRC | 15:00 | |
*** noisecell has quit IRC | 15:28 | |
*** noisecell has joined #baserock | 15:28 | |
*** gtristan has joined #baserock | 15:30 | |
*** toscalix has joined #baserock | 15:49 | |
*** toscalix has quit IRC | 15:55 | |
*** noisecell has quit IRC | 16:06 | |
*** toscalix has joined #baserock | 16:08 | |
*** toscalix has quit IRC | 16:11 | |
*** toscalix has joined #baserock | 16:14 | |
*** toscalix has quit IRC | 16:15 | |
*** toscalix has joined #baserock | 16:18 | |
*** toscalix has quit IRC | 16:23 | |
*** ctbruce has quit IRC | 16:24 | |
*** Guest58527 has quit IRC | 16:29 | |
*** toscalix has joined #baserock | 16:38 | |
*** CTtpollard has quit IRC | 16:40 | |
*** toscalix has quit IRC | 16:45 | |
*** CTtpollard has joined #baserock | 16:55 | |
*** jonathanmaw has quit IRC | 17:36 | |
*** jude_ has quit IRC | 17:56 | |
*** toscalix has joined #baserock | 18:10 | |
*** locallycompact has quit IRC | 18:13 | |
*** ssam2 has quit IRC | 18:25 | |
*** toscalix has quit IRC | 19:16 | |
*** rdale has quit IRC | 19:36 | |
*** jude_ has joined #baserock | 19:41 | |
*** toscalix has joined #baserock | 20:36 | |
*** locallycompact has joined #baserock | 21:07 | |
*** toscalix has quit IRC | 21:28 | |
*** jude_ has quit IRC | 22:43 | |
*** locallycompact has quit IRC | 23:24 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!