| *** Prince781 has quit IRC | 00:03 | |
| *** Prince781 has joined #buildstream | 06:11 | |
| *** toscalix has joined #buildstream | 07:22 | |
| *** Prince781 has quit IRC | 07:36 | |
| *** toscalix has quit IRC | 07:45 | |
| *** toscalix has joined #buildstream | 07:55 | |
| *** finn has joined #buildstream | 08:01 | |
| finn | Hey, for the RWAPI & REAPI implementations, I'm thinking of going for BuildGrid unless anyone manages to persuade me otherwise by the end of the day | 08:24 |
|---|---|---|
| *** noisecell has joined #buildstream | 08:24 | |
| *** jennis has joined #buildstream | 08:50 | |
| *** sstriker has joined #buildstream | 09:06 | |
| *** bethw has joined #buildstream | 09:10 | |
| *** jonathanmaw has joined #buildstream | 09:17 | |
| *** tiago has joined #buildstream | 09:23 | |
| *** jonathanmaw has quit IRC | 09:42 | |
| toscalix | agenda for this afternoon's meeting sent | 09:52 |
| Nexus | ty | 09:56 |
| *** jonathanmaw has joined #buildstream | 09:57 | |
| *** ernestask has joined #buildstream | 10:02 | |
| *** aday has joined #buildstream | 10:24 | |
| *** aday has quit IRC | 10:39 | |
| *** aday has joined #buildstream | 10:40 | |
| *** tiago has quit IRC | 10:44 | |
| *** tiago has joined #buildstream | 10:57 | |
| *** bochecha_ has joined #buildstream | 11:17 | |
| gitlab-br-bot | buildstream: merge request (chandan/add-argument-bst-pushreceive->master: _artifactcache/pushreceive.py: Add Click type for CLI argument 'repo') #476 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/476 | 11:23 |
| *** bochecha_ has quit IRC | 11:25 | |
| tlater | finn: The name for our buildfarm implementation might be a thing to quickly raise during the 3 pm meeting :) | 11:25 |
| * tlater does suggest going with "BuildGrid" by default, and asking for objection rather than suggestion | 11:26 | |
| finn | ssander already agreed on BuildGrid | 11:26 |
| finn | But you can still raise it briefly if you want :) | 11:26 |
| tlater | Heh, just announce the new buildstream project then ;) | 11:27 |
| *** bochecha_ has joined #buildstream | 11:27 | |
| toscalix | tlater: hot topic section | 11:31 |
| gitlab-br-bot | buildstream: merge request (juerg/googlecas->master: Remote Execution CAS-based artifact cache) #337 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/337 | 11:48 |
| gitlab-br-bot | buildstream: issue #409 ("bst-artifact-receive: CLI should not throw stacktrackes when repo argument is invalid") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/409 | 11:53 |
| gitlab-br-bot | buildstream: merge request (chandan/add-argument-bst-pushreceive->master: _artifactcache/pushreceive.py: Add Click type for CLI argument 'repo') #476 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/476 | 11:55 |
| gitlab-br-bot | buildstream: merge request (chandan/add-argument-bst-pushreceive->master: _artifactcache/pushreceive.py: Add Click type for CLI argument 'repo') #476 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/476 | 11:56 |
| finn | config files for the bots (which tell them how many devices they have etc.) - this ok in YAML format? | 12:12 |
| *** sstriker has quit IRC | 12:12 | |
| tlater | finn: How will the bots be configured? | 12:14 |
| tlater | is this a cluster thing where you'll need to configure many at the same time? | 12:15 |
| finn | So at the moment a bot will register with the server, telling the server what resources it has. The server then registers this bot. I don't think the API specifies how bots are to be configured | 12:16 |
| * tlater may know too little about the actual process, but doesn't think configuring each bot with a yaml file individually scales | 12:18 | |
| finn | How else would the bot know what devices it has? | 12:18 |
| finn | I'd thought providing a default config to each bot would be sensible, the default can be changes or added to | 12:19 |
| tlater | Yeah, I'm fairly sure I just don't know what the bots need to know in enough detail :) | 12:19 |
| tlater | It would be nice if the server could just tell them how to act, though. | 12:19 |
| finn | A worker is a machine, physical or virtual. It could be a self-contained computer or it could include devices such as printers or phones. Workers run a bot which communicates with a central service to request work. It makes more sense to me, to have a configuration file per worker. | 12:24 |
| finn | They'll have to run a "bot" anyway | 12:24 |
| tlater | Well, assuming we need configuration files for all bots, I think yaml makes the most sense since that's the general buildstream config format | 12:26 |
| tlater | Unless the server implementation uses something else? | 12:26 |
| finn | What do you mean by the server implementation using something else? | 12:30 |
| *** cs_shadow has joined #buildstream | 12:31 | |
| cs_shadow | This CI failure - https://gitlab.com/BuildStream/buildstream/-/jobs/71058841 - seems unrelated to the change. Any ideas why it might be caused before I hit rebuild? | 12:32 |
| finn | The API just states: "In the REAPI, the worker message is used to describe the requirements, whereas in RWAPI, it is used to describe the capabilities" - the capabilities are probably better described per bot which are loaded into the bot client before it registers with the server | 12:35 |
| tlater | finn: Does the server have to be configured? | 12:41 |
| tlater | cs_shadow: jmac recently ran into this as well, iirc | 12:42 |
| tlater | We think it's a rare issue caused by leftover state from previous test cases | 12:42 |
| finn | tlater, no, apart from the obvious things like what address to make calls on | 12:43 |
| tlater | It would be nice if someone could figure out why it happens in detail, but it's probably very hard to debug | 12:43 |
| tlater | finn: So it won't need a configuration file at all? | 12:43 |
| tlater | In that case, yaml seems fine | 12:43 |
| finn | The server? Probably not, though I haven't thought about how you'd expose the ports etc | 12:44 |
| tlater | As long as they use the same format it's fine :) | 12:44 |
| cs_shadow | tlater: I guessed so. I'll hit the rebuild on this one and will keep an eye out for it in future | 12:47 |
| *** jonathanmaw has quit IRC | 12:48 | |
| *** jonathanmaw has joined #buildstream | 12:48 | |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 12:54 |
| gitlab-br-bot | buildstream: merge request (caching_build_trees->master: WIP: Caching buildtrees) #474 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/474 | 12:56 |
| *** ernestask has quit IRC | 12:59 | |
| gitlab-br-bot | buildstream: merge request (caching_build_trees->master: WIP: Caching buildtrees) #474 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/474 | 13:18 |
| Nexus | regarding "Source code available in environment in order to debug. | 13:30 |
| Nexus | " | 13:30 |
| Nexus | what is the background for this task, is there more to it than just maknig the sourcecode accessable in a workspace? | 13:31 |
| Nexus | e.g. in what scenario should it be available? All the time, when a flag is active, when a flag isn't active, on a failed build? etc | 13:31 |
| tlater | Nexus: If you're in a `bst shell`, and you're trying to run, for example, gdb, you need the source code to actually debug | 13:32 |
| * tlater thinks the relevant element being workspaced is probably what should enable this. | 13:32 | |
| tlater | You do raise an interesting note with the failed build in this case | 13:34 |
| tlater | Though I guess it doesn't matter much if opening the workspace automatically stages the source next to the artifact without a rebuild | 13:34 |
| * tlater isn't sure whether that happens | 13:35 | |
| *** xjuan has joined #buildstream | 13:36 | |
| *** sstriker has joined #buildstream | 13:46 | |
| Nexus | tlater: is this assuming that the build for that element failed of suceeded? | 13:57 |
| Nexus | o* | 13:57 |
| Nexus | r | 13:57 |
| tlater | No, we want sources in either case, a successful build may still be buggy | 13:58 |
| tlater | And a failed build may still have working binaries | 13:58 |
| Nexus | kk | 13:58 |
| laurence | nb all - monthly meeting has started over in #buildstream-meetings | 14:01 |
| *** sstriker has quit IRC | 14:11 | |
| *** Prince781 has joined #buildstream | 14:14 | |
| *** Prince781 has quit IRC | 14:43 | |
| *** solid_black has joined #buildstream | 14:52 | |
| *** xjuan has quit IRC | 15:10 | |
| *** xjuan has joined #buildstream | 15:11 | |
| *** ernestask has joined #buildstream | 15:14 | |
| *** xjuan has quit IRC | 15:15 | |
| *** tiago has quit IRC | 15:33 | |
| *** xjuan has joined #buildstream | 15:35 | |
| *** Prince781 has joined #buildstream | 15:49 | |
| *** solid_black has quit IRC | 15:53 | |
| toscalix | juergbi: it seems a bug we thought it was closed might have showed up again. It is https://gitlab.com/BuildStream/buildstream/issues/405 | 16:10 |
| toscalix | I would appreciate if you take a look anytime soon at least to say of we are talking about the same issue or a different one | 16:11 |
| toscalix | may I assign it to you so you remember which one is it? | 16:11 |
| juergbi | sure | 16:11 |
| toscalix | done, thanks | 16:13 |
| tlater | I'm trying to write a plugin that only stages direct dependencies of an element | 16:17 |
| tlater | Looking at stage_dependency_artifacts, it seems to unconditionally use dependencies with recurse=True | 16:18 |
| tlater | Since I'm using a plugin I can't change that - is there any way around this? Reimplementing stage_dependency_artifacts isn't an option since it carries a fair bit of functionality. | 16:19 |
| juergbi | tlater: i.e., stage_artifact would be too low level for you? | 16:24 |
| juergbi | isn't the main part of stage_dependency_artifacts about overlap etc. handling which doesn't make sense if you don't include dependencies? | 16:25 |
| tlater | Oh, yeah, that is a point | 16:25 |
| juergbi | I probably need more context for a better answer | 16:25 |
| juergbi | btw: also see Filter element | 16:26 |
| tlater | Ta, haven't had a look at that yet at all | 16:26 |
| tlater | juergbi: The problem is mostly that I'd like to have a pipeline with a base platform that isn't part of `bst checkout`, but can be used for `bst shell` | 16:30 |
| * tlater has run into this a few times and doesn't seem to find a way around this | 16:31 | |
| gitlab-br-bot | buildstream: issue #405 ("bst is still pushing artifacts it just have pulled") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/405 | 16:31 |
| cs_shadow | @tlater maybe one solution could be to add a `--deps [all,none]` option to `bst checkout`. That way when you only want to checkout the output of the given element(s), you would run with `--deps none` | 16:33 |
| cs_shadow | admittedly, this isn't very tidy | 16:34 |
| tlater | It also only works until runtime dependencies become part of what I'd like to deploy | 16:34 |
| tlater | Not that deployment is buildstream's problem, but preparing an artifact ready to deploy should probably be | 16:35 |
| *** toscalix has quit IRC | 16:38 | |
| * tlater wonders if making platforms a special thing would make buildstream neater overall | 16:41 | |
| tlater | We could then also warn if there was no base platform and suchlike | 16:41 |
| cs_shadow | although I haven't come across such a project before but I imagine it's possible to have a project without any base platform, where you basically just copy stuff around until you have something that resembles a base platform | 17:00 |
| tlater | cs_shadow: Would that something then not amount to the "base platform"? | 17:01 |
| * tlater agrees that buildstream's flexibility here is very nice, but finds that it's a bit in the way sometimes | 17:01 | |
| cs_shadow | tlater: Maybe but everything that it depends on will not have a platform | 17:01 |
| cs_shadow | i agree that for most practical use cases, treating the platform in a more special may result in a nicer DX | 17:03 |
| *** bethw has quit IRC | 17:04 | |
| *** jonathanmaw has quit IRC | 17:12 | |
| *** xjuan_ has joined #buildstream | 17:18 | |
| gitlab-br-bot | buildstream: issue #405 ("bst is still pushing artifacts it just have pulled") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/405 | 17:20 |
| *** xjuan has quit IRC | 17:21 | |
| *** ernestask has quit IRC | 17:33 | |
| *** ernestask has joined #buildstream | 17:35 | |
| *** Prince781 has quit IRC | 18:57 | |
| *** ernestask has quit IRC | 19:33 | |
| *** aday has quit IRC | 19:36 | |
| *** xjuan_ has quit IRC | 20:05 | |
| gitlab-br-bot | buildstream: issue #410 ("Dog-Fooding: Build BuildStream with BuildStream") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/410 | 21:22 |
| *** Nexus has quit IRC | 23:11 | |
| *** Nexus has joined #buildstream | 23:11 | |
| *** jmac has quit IRC | 23:11 | |
| *** jmac has joined #buildstream | 23:11 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!