| *** brlogger has joined #buildstream | 03:55 | |
| *** irc.acc.umu.se sets mode: -o brlogger | 03:55 | |
| *** hergertme has joined #buildstream | 03:55 | |
| *** jjardon[m] has joined #buildstream | 03:55 | |
| *** paulsher1ood has joined #buildstream | 03:55 | |
| *** juergbi has joined #buildstream | 03:55 | |
| *** persia has joined #buildstream | 03:55 | |
| *** irc.acc.umu.se sets mode: +ntr | 03:55 | |
| *** irc.acc.umu.se changes topic to "BuildStream 0.1 is out ! | https://gitlab.com/BuildStream/buildstream | Docs: https://people.gnome.org/~tvb/buildstreamdocs/ | IRC logs: https://irclogs.baserock.org/buildstream | Roadmap: https://wiki.gnome.org/Projects/BuildStream/Roadmap" | 03:55 | |
| *** kurbeco has joined #buildstream | 03:56 | |
| *** tiagogomes has joined #buildstream | 03:58 | |
| *** leeming has joined #buildstream | 03:58 | |
| *** tristan has joined #buildstream | 04:21 | |
| *** ChanServ sets mode: +o tristan | 05:15 | |
| *** tristan changes topic to "BuildStream 0.1 is out ! | https://gitlab.com/BuildStream/buildstream | Docs: https://buildstream.gitlab.io/buildstream | IRC logs: https://irclogs.baserock.org/buildstream | Roadmap: https://wiki.gnome.org/Projects/BuildStream/Roadmap" | 06:52 | |
| tristan | Awesome gitlab, any merge to master: Automatically generates docs at: https://buildstream.gitlab.io/buildstream | 06:53 |
|---|---|---|
| paulsher1ood | tristan: w00t! | 09:01 |
| paulsher1ood | maybe it would make sense to add the roadmap there? | 09:02 |
| tristan | paulsher1ood, I dont think so, rather there are better ways to do this :) | 09:06 |
| tristan | paulsher1ood, we can have a website for the BuildStream "group" | 09:06 |
| tristan | Where we can refer to things, and point to the docs from there etc | 09:07 |
| tristan | then buildstream.gitlab.io is the main website, and buildstream.gitlab.io/buildstream is the project documentation | 09:07 |
| tristan | Then again, whether you maintain your roadmap in your actual repository, is a matter of taste I guess | 09:08 |
| tristan | some people have TODO files and such, but I feel it avoids clutter to keep that tracked in external resources and bug trackings | 09:09 |
| paulsher1ood | your call, t'was just a suggestion | 09:11 |
| tristan | I think it will be nice to have a website for the group :) | 09:13 |
| tristan | regardless of where we keep the roadmap | 09:14 |
| tristan | juergbi, fyi I'm making some artifact cache changes | 09:14 |
| tristan | juergbi, first step, I've moved over to using the Element directly as API (as you suggested, but artifacts came before Elements were completely there), and updated test cases | 09:15 |
| tristan | But beyond that, I want to encode some more into artifacts, for instance some metadata, and I dont want the metadata to be in the actual artifact content | 09:16 |
| tristan | Also, I want to include the build log at commit() time | 09:16 |
| tristan | (again, not part of the actual content) | 09:16 |
| tristan | So in shared cache cases, we always have some provenance about where the artifact was built and such (in the full build log) | 09:17 |
| tristan | Also the metadata I realize is going to be needed for some more fancy things | 09:17 |
| tristan | for instance, it solves the problem of stratifying (or _not_ rather) of projects you depend on (recursive pipelines), as a pipeline element (or a "stack" for that matter) makes a statement of all the cache keys which it depends on | 09:18 |
| tristan | so you can recursively fetch the artifacts you need to stage, if you have their cache keys in the artifact metadata (of a stack or pipeline element) | 09:19 |
| * tristan thinks this might have been a reason why morph was doing this, even though I dont see it being in use really | 09:20 | |
| tristan | Also, it provides a way that we can propagate public data through the artifact | 09:21 |
| tristan | (like integration commands, which could be automatically derived from pipelines you depend on) | 09:21 |
| tristan | some inspiration came from going over that roadmap again | 09:22 |
| paulsher1ood | if you're changing test cases, can you drop 'the pony' and go for something that makes obvious sense to a new potential contributor? | 09:31 |
| tristan | I just updated artifact cache tests so they would continue to pass | 09:32 |
| paulsher1ood | ack | 09:32 |
| tristan | everything costs work, and I'm not opposed to changing ponies for other thingies if the result is more clear (it takes imagination though to name things well in test data sets) | 09:33 |
| tristan | but I wont be considering test cases to be exemplary of how to use buildstream | 09:34 |
| tristan | we should have demos / examples for that purpose | 09:34 |
| juergbi | tristan: ok, makes sense. i think we should keep most of the metadata inside the actual artifact. if necessary, we could have an option to skip extraction of that part | 10:40 |
| tristan | juergbi, at first I wanted to have one artifact with a content/ subdir | 10:41 |
| tristan | but that causes some complications, cant easily achieve that without moving things on disk | 10:41 |
| juergbi | i agree that some things may make sense outside the actual artifact, though. artifact cache keys of dependencies and build logs might actually make sense | 10:41 |
| tristan | I just think that what constitutes the content of the artifact is not the metadata, as soon as we add any file into the content we place some restriction (namespace clutter) on what an artifact can contain | 10:42 |
| tristan | So, for instance if we sneak things into an artifact, maybe an artifact is no longer allowed to actually distribute something in '/buildstream' | 10:43 |
| tristan | as unlikely as it seems, separating that is the pedantic thing to do | 10:43 |
| juergbi | true. may have to decide based on a list of specific metadata | 10:43 |
| juergbi | build log and artifact cache keys of dependencies make sense outside | 10:43 |
| tristan | Yes, they could live together in a counterpart | 10:44 |
| tristan | Another thing is, right now I have this hack in the "stack" element, which creates stuff in the artifact | 10:44 |
| tristan | because ostree pukes when you commit an empty directory | 10:44 |
| tristan | anyway a little more thought on how it comes together is needed I guess, but certainly we can support artifacts without content (like stacks, or potentially pipelines, which just make a statement that their dependencies have been built) | 10:46 |
| juergbi | ostree should probably support this (possibly with a flag like git's --allow-empty) | 10:47 |
| tristan | nod, maybe so :) | 10:47 |
| tristan | but if we read the metadata first, we can also easily work around that | 10:47 |
| tristan | (which is probably appropriate, given the time it will take for a change in ostree to reach distros) | 10:48 |
| tristan | I was also wondering if ostree supports creating a commit from different sources | 10:49 |
| tristan | if that's already supported, that can help | 10:49 |
| tristan | i.e. "Take this directory, and put it in /content of your commit, also take this /long/path, and put it there as /build.log" | 10:50 |
| tristan | all in one atomic commit | 10:50 |
| juergbi | on the low level it would likely be simple. no idea whether the API allow sit | 10:50 |
| juergbi | *allows it | 10:50 |
| tristan | nod | 10:50 |
| tristan | needs investigation, was perusing the source today | 10:50 |
| tristan | also I'm not sure what character set exactly is allowed in a ref | 10:51 |
| * tristan has a substitution to support element names which contain '+' | 10:51 | |
| tristan | for things like libstdc++.bst | 10:51 |
| tristan | couldnt find that in the sources easily though :-/ | 10:52 |
| *** tristan has quit IRC | 10:57 | |
| *** tristan has joined #buildstream | 11:04 | |
| *** ChanServ sets mode: +o tristan | 11:05 | |
| *** ironfoot_ has joined #buildstream | 11:32 | |
| *** ironfoot_ has quit IRC | 11:38 | |
| *** jude has joined #buildstream | 11:53 | |
| *** jude has quit IRC | 15:03 | |
| *** ironfoot_ has joined #buildstream | 15:38 | |
| *** ironfoot_ has joined #buildstream | 15:40 | |
| *** ironfoot_ is now known as ironfoot | 15:40 | |
| *** ChanServ sets mode: +o ironfoot | 15:40 | |
| *** tiagogomes has quit IRC | 17:23 | |
| *** tristan has quit IRC | 20:18 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!