| *** tristan has joined #buildstream | 07:00 | |
| *** ChanServ sets mode: +o tristan | 07:00 | |
| * tristan now has 3 PRs on the friar... | 09:46 | |
| tristan | juergbi, I don't recall why pull-artifact-files is allowed to be specifically set to False even when there is no RE service | 11:08 |
|---|---|---|
| tristan | Should it really reside within the `remote-execution` config block in that case ? | 11:09 |
| nanonyme | tristan, I don't think it's necessarily undesirable, it just makes me wonder if we're understanding RE right withing scope of the new cache | 12:10 |
| nanonyme | jjardon, oops, meant that to you | 12:10 |
| nanonyme | tristan, you obviously understand it right, I was mainly trying to figure out from your post whether we are | 12:11 |
| jjardon | nanonyme: I think we are, that's why we started the asset server project for example | 12:13 |
| nanonyme | jjardon, right. But eg what does that exactly mean that you could not define RE service in project configuration, only user configuration | 12:14 |
| nanonyme | With regards to our CI it doesn't really matter since we can in CI generate expected user configuration. But what are the exact implications for dev machines? | 12:15 |
| *** tristan has quit IRC | 12:19 | |
| *** tristan has joined #buildstream | 12:22 | |
| *** ChanServ sets mode: +o tristan | 12:22 | |
| tristan | I think what I understand from that setting is, whether we want to download the artifact files after a build completes | 12:24 |
| tristan | My question is rather, how that is useful if the build is happening locally | 12:24 |
| jjardon | nanonyme: for what I understand most of the config (specially the one that allows write access to remote services) will be moved to buildstream.conf ? Although some "hints" can be left in project.conf ? | 12:24 |
| tristan | The current code allows configuring this setting without having a remote execution service configured, which I don't understand the logic behind | 12:24 |
| tristan | I seem to vaguely recall that there was some reason for this, though | 12:25 |
| tristan | Regarding user configuration, techinically anything that does not define what a project *is* is user configuration, and in some corner cases project.conf is allowed to provide a suggestion/recommendation for user configuration: This must always be overridable by user configuration | 12:27 |
| tristan | user configuration specifies how to run a build, but not the content of a build, as such it never affects cache keys and in theory at least should not affect how builds run | 12:28 |
| tristan | https://lists.apache.org/thread.html/rf2da9830e2fa918357f99a6021e55fc43df876f0b19d43f68802f083%40%3Cdev.buildstream.apache.org%3E This proposal suggests we remove a mountain of complexity | 12:28 |
| jjardon | Yeah, I think we are working more or less like that on other projects: project.conf define the "default" read only cache; if someone have access to write (CI server) we override the config in the CI job | 12:29 |
| tristan | one of the ways we do that is by at least admitting that if you have write access to a service, you will anyway need a priviledged key of some sort | 12:29 |
| tristan | In which case it doesn't make much sense supporting that suggestion in project.conf, since you can just as well set it up in buildstream.conf | 12:29 |
| tristan | since you will anyway need to provide that key separately | 12:29 |
| jjardon | I think that makes sense | 12:30 |
| tristan | that's not the same as read access, which can sometimes involve a key for signature verifications | 12:30 |
| tristan | like a gpg key makes sense to store with a project, it's no secret | 12:30 |
| jjardon | Yeah, or to verify a public ostree repo to use it as a source | 12:31 |
| tristan | exactly the example I was referring to :) (but could make sense in other scenarios too of course) | 12:32 |
| jjardon | nanonyme: so I think for us nothing will change as we already put "write" config in buildstream.conf : https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/master/.gitlab-ci.yml#L67 | 12:51 |
| *** tristan has quit IRC | 13:04 | |
| *** tristan has joined #buildstream | 13:06 | |
| *** ChanServ sets mode: +o tristan | 13:06 | |
| *** dftxbs3e_ has quit IRC | 14:50 | |
| *** dftxbs3e_ has joined #buildstream | 14:50 | |
| nanonyme | jjardon, right. It's mostly that tristan commented there that there's no "read-only" configuration for RE. Hence it can only be configured in user config, not project config | 15:07 |
| nanonyme | If I understood correctly | 15:07 |
| nanonyme | But maybe the important difference here is "having a cache that uses RE API's" and "using RE"? | 15:08 |
| nanonyme | We most definitely need to be able to configure our cache such that developers can more or less automatically consume artifacts created through CI | 15:09 |
| jjardon | nanonyme: yeah, I think you are right | 16:07 |
| *** tristan has quit IRC | 16:12 | |
| *** toscalix has joined #buildstream | 17:42 | |
| *** toscalix has quit IRC | 23:58 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!