*** juergbi has quit IRC | 02:39 | |
*** juergbi has joined #buildstream | 02:41 | |
*** tristan has quit IRC | 06:20 | |
*** tristan has joined #buildstream | 06:40 | |
*** ChanServ sets mode: +o tristan | 06:40 | |
*** jonathanmaw has joined #buildstream | 08:31 | |
jonathanmaw | morning tristan, I've run into a problem with how to run the integration commands when setting up the staging area. When you install contents into a subdir, integration commands can't be reliably executed. My solution was to extend the sandbox class to be able to create a sub-sandbox, which I can run the commands from | 08:42 |
---|---|---|
tristan | jonathanmaw, I was hoping to talk to you about that yeah | 08:44 |
tristan | jonathanmaw, I came to the opposite conclusion actually | 08:45 |
tristan | I thought, there is an expense of making the sandbox API more complex | 08:45 |
tristan | And there is a discomfort of not allowing integration commands in sandbox "sub stages" | 08:45 |
tristan | jonathanmaw, the thing is, the user can always stage the output of a "compose" element into a script subdir, if they want to stage something pre-integrated | 08:46 |
tristan | So I feel like, probably it's not worth adding more complexity to the sandbox to satisfy that | 08:46 |
jonathanmaw | Ok, works for me! | 08:46 |
tristan | and just say that "Only elements staged in / will have integration commands run" | 08:47 |
*** tiagogomes has joined #buildstream | 09:11 | |
gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 3 commits (last: _signals.py: Added blocked() context manager) https://gitlab.com/BuildStream/buildstream/commit/304a35e8a53e50903fb4d1d06c19827dcef9cd7d | 09:31 |
jonathanmaw | does get_unique_key need to pull in all the variables for an element, too? | 09:44 |
tristan | jonathanmaw, no | 09:45 |
tristan | well wait a sec... | 09:45 |
tristan | it does not but.... | 09:45 |
* jonathanmaw had a peek at element._get_cache_key | 09:45 | |
jonathanmaw | ah, those were environment variables, not Variables | 09:46 |
tristan | jonathanmaw, basically, what is expected is that any self.node_subst_member() be used in configure() | 09:47 |
tristan | So once you have loaded your configuration, you have loaded it with variables substituted | 09:47 |
tristan | If any variables have been used to compose the configuration | 09:47 |
tristan | the values of only those variables will effect the cache key | 09:47 |
jonathanmaw | ok, so variables include cwd, and the element should pull that out in configure and store it locally, to set get_unique_key | 09:48 |
tristan | jonathanmaw, exactly, basically all configuration should be loaded in at self.configure() time | 09:50 |
* paulsher1ood hopes folks don't accidentally do anything that defeats the possibility of bit-for-bit reproducible builds | 09:50 | |
tristan | paulsher1ood, I suppose a measure we can take against that is to raise an exception if ever variable substitutions are attempted outside of configure() | 09:50 |
tristan | But, there is no way to to make it entirely bullet proof | 09:51 |
tristan | improving documentation where possible should be a priority | 09:51 |
paulsher1ood | akc... but at some point, once we have bst definitions that are in themselves b4b, we can put that in as a ci test | 09:51 |
tristan | Yes, but that does not mean that third parties can never make a mistake in their own custom plugins | 09:52 |
tristan | We can only police the plugins we maintain | 09:52 |
paulsher1ood | ack | 09:52 |
tristan | basically though, the only obvious opportunity I can see for messing up is rudely interrogating the host environment (os.environ dictionary) | 09:53 |
paulsher1ood | :) | 09:54 |
gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 1 commit (last: element.py: Fixed dumb mistake bad bitwise operation) https://gitlab.com/BuildStream/buildstream/commit/276d544bd9190b3faaa3b968d7aab3f23dfdc4fc | 10:05 |
gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 1 commit (last: _sandboxbwrap.py: Fix issue #31, handle keyboard interrupts) https://gitlab.com/BuildStream/buildstream/commit/a0b0de9a2351d2fb47b325fdc0cc07e0058b7b50 | 10:12 |
gitlab-br-bot | buildstream: issue #31 ("Hitting ^C inside the shell causes stack trace in the frontend and orphaned tasks") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/31 | 10:12 |
jonathanmaw | hrm, I think when I was originally setting this out, I was assuming read-only sandboxing was set some other way. | 10:14 |
jonathanmaw | tristan: Should I extend sandbox.run to understand a list of read-only dirs? | 10:15 |
tristan | nah | 10:15 |
tristan | readonlyness is only a feature for / | 10:15 |
jonathanmaw | ok | 10:16 |
tristan | anything under staged under the special '/buildstream' directory (if it exists), is readwrite | 10:16 |
tristan | jonathanmaw, there is a critical bug related to this which must be handled... but there is no way out anyway | 10:16 |
tristan | there is always a case where read-write is required on a staged artifact | 10:17 |
tristan | (like when running integration commands) | 10:17 |
jonathanmaw | ok, so it sounds like read-only root would be better passed in as config or a variable, rather than being part of layout. | 10:17 |
jonathanmaw | unless we're leaving space for it to be extended to provide that functionality later. | 10:18 |
tristan | jonathanmaw, sure, outside of layout sounds suitable | 10:18 |
tristan | note that bug I was referring to is: https://gitlab.com/BuildStream/buildstream/issues/19 | 10:18 |
tristan | I hope to fix that with fusepy to provide a "copy-on-write hardlink" experience for anything read-write | 10:19 |
tristan | or anything read-write which "comes from an artifact" | 10:19 |
tristan | not needed for anything that comes from Sources | 10:19 |
jonathanmaw | tristan: I'm not sure on how to decide whether to put "readonly-root" in variables or config. | 10:20 |
jonathanmaw | Is it "whether it would conceivably be used in scripts"? | 10:20 |
jonathanmaw | or "Is it simple enough to be expressed as a string"? | 10:20 |
*** tiagogomes has quit IRC | 10:28 | |
*** tiagogomes has joined #buildstream | 10:29 | |
tristan | jonathanmaw, good question | 10:30 |
tristan | not sure I know the answer, but my intuition would be to put it in config | 10:31 |
tristan | I think the former is a decent criteria | 10:31 |
jonathanmaw | ok | 10:32 |
paulsher1ood | tristan: s/criteria/criterion/ | 10:43 |
*** tristan has quit IRC | 11:41 | |
*** tristan has joined #buildstream | 13:11 | |
*** ChanServ sets mode: +o tristan | 13:11 | |
gitlab-br-bot | buildstream: issue #35 ("End of session reports") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/35 | 13:45 |
gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 1 commit (last: element.py: Protect against variable substitutions outside of Element.configure()) https://gitlab.com/BuildStream/buildstream/commit/ad48cee1171c465bad966d2cb1c8f120fca67176 | 13:52 |
*** tristan has quit IRC | 14:03 | |
*** tristan has joined #buildstream | 14:11 | |
*** ChanServ sets mode: +o tristan | 14:58 | |
*** jude has quit IRC | 16:09 | |
jonathanmaw | \o/ I'm through enough of the bugs in my code that it's started building! | 16:22 |
jonathanmaw | I don't think I'm going to see the result of this build until tomorrow, though :¬| | 16:22 |
*** jude has joined #buildstream | 16:28 | |
jonathanmaw | turns out I did see the result. It failed :P | 16:30 |
*** jonathanmaw has quit IRC | 17:04 | |
*** jude has quit IRC | 17:11 | |
*** jude has joined #buildstream | 17:19 | |
*** Chris has quit IRC | 17:22 | |
*** Chris has joined #buildstream | 17:23 | |
*** jude has quit IRC | 17:53 | |
*** jude has joined #buildstream | 20:24 | |
*** tristan has quit IRC | 20:40 | |
*** jude has quit IRC | 21:01 | |
*** violeta_ has quit IRC | 21:21 | |
*** paulsher1ood has quit IRC | 22:34 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!