| *** juergbi <juergbi!juerg@2a01:4f8:252:fc00:b060:4fff:fe7d:3f28> has quit IRC | 03:51 | |
| *** juergbi <juergbi!juerg@2a01:4f8:252:fc00:b060:4fff:fe7d:3f28> has joined #buildstream | 03:52 | |
| *** juergbi <juergbi!juerg@2a01:4f8:252:fc00:b060:4fff:fe7d:3f28> has quit IRC | 05:03 | |
| *** juergbi <juergbi!juerg@rome.bitron.ch> has joined #buildstream | 05:05 | |
| SamThursfield[m] | yes, i don't think adding a string option type is the right solution - a user-modified yml file is a good option (or just use project.yaml, but i guess you have some case where that isn't ideal :) | 12:19 |
|---|---|---|
| SamThursfield[m] | its nice that with the current option types, you can actually enumerate and exhaustively test all possible project configs | 12:19 |
| nanonyme | I guess one way is to have multiple elements of the variations and user selects which one to build | 14:30 |
| AdrianVovk[m] | It's not a defined set of variations | 15:37 |
| AdrianVovk[m] | Essentially I need a way for people to configure a URL that the update service checks for | 15:37 |
| AdrianVovk[m] | * Essentially I need a way for people to configure a URL where the update service should check for updates | 15:37 |
| AdrianVovk[m] | So for development it'd be set to a local IP address of the build machine, the CI server would be pushing to a special staging remote, and production builds would go up to the production updates server | 15:38 |
| AdrianVovk[m] | So you suggest a yml config file I ask people building the OS to edit and exclude from git? | 15:39 |
| AdrianVovk[m] | <SamThursfield[m]> "its nice that with the current..." <- Frankly that's up to the project, no? | 15:42 |
| AdrianVovk[m] | Excluding from git in that way would break completely whenever an option is added. And someone just trying to make a local build of the OS shouldn't need to patch out the update URLs. Nor should my CI system be patching config files | 15:44 |
| SamThursfield[m] | well, this is my understanding of the design philosophy - i am not in a position to change that. i agree it can be limiting | 15:54 |
| SamThursfield[m] | the other concern is making things reproducible from Git. but regarding infrastructure URLs its rather an exception anyway | 15:55 |
| SamThursfield[m] | what you can do is inject files into the build fairly easily though | 15:57 |
| SamThursfield[m] | so in the case of an update URL, you might have a file in the project repo, "update_service_url". The contents of that file are committed to Git, and that would be the default value | 15:58 |
| SamThursfield[m] | then for local builds, either the user or a helper script would override that file with whatever the local IP of the build machine is | 15:58 |
| SamThursfield[m] | i've found that having a wrapper script around bst build to set up things like this can be very useful | 15:59 |
| SamThursfield[m] | let's consider the "opposite" possibility, that someone adds a flag to bst that lets you override any project variable on the commandline. So your use case could be a convenient thing like bst --override-variable update_server_url=${machine_url} build ... | 16:01 |
| SamThursfield[m] | this creates a whole new possibility of bad practices that can be done, producing builds with special magic contents that nobody can later reproduce | 16:02 |
| SamThursfield[m] | still, maybe it's worth the risk - people will always be able to shoot themselves in the foot if they want to. i don't know | 16:02 |
| nanonyme | I'm not sure if it does much else than breaks cache keys | 17:29 |
| nanonyme | With bst shell you can of course pass environment variables | 17:30 |
| AdrianVovk[m] | Why one extreme to another? I'm not asking for the ability to override any project variable. Just those the project defines to be options... | 19:47 |
| AdrianVovk[m] | Options have default values that the project would (presumably) use in production | 19:48 |
| AdrianVovk[m] | I don't quite see why allowing the builder to pass `-o debug True` on the command line is any different than `-o some-url http://192.168.180.10` | 19:49 |
| AdrianVovk[m] | Going the route of injecting a yml file or whatever is just reinventing bst options, BUT now you lose features like: | 19:51 |
| AdrianVovk[m] | - the ability to override these options from the user config file | 19:51 |
| AdrianVovk[m] | - the ability for upstream to change the options in any way (defaults, add more, whatever) without causing a big ruckus for every builder | 19:51 |
| AdrianVovk[m] | Ultimately the computed cache keys will take the value of the option into effect on the elements that read from it. So: no, cache keys wouldn't break. They'd change when the option is changed but that's BST working as intended | 19:53 |
| AdrianVovk[m] | <nanonyme> "With bst shell you can of course..." <- Bst shell cannot produce elements | 19:53 |
| AdrianVovk[m] | <SamThursfield[m]> "this creates a whole new..." <- I mean sure? Projects doing those bad practices can also just not commit some of their bst files to git and then have unreproducible builds that way | 19:55 |
| *** robjh[m] <robjh[m]!~robjhm@2001:470:1af1:104:0:0:0:48ba> has quit IRC | 22:12 | |
| *** jjardon[m] <jjardon[m]!jjardonmat@2001:470:1af1:104:0:0:0:224c> has quit IRC | 22:12 | |
| *** wsalmon[m] <wsalmon[m]!wsalmonmat@2001:470:1af1:104:0:0:0:5c0b> has quit IRC | 22:12 | |
| *** TheMuso[m] <TheMuso[m]!themuso82m@2001:470:1af1:104:0:0:0:4d68> has quit IRC | 22:12 | |
| *** JrgBilleter[m] <JrgBilleter[m]!juergbimat@2001:470:1af1:104:0:0:0:6317> has quit IRC | 22:12 | |
| *** doras <doras!doras@2001:470:1af1:104:0:0:0:220b> has quit IRC | 22:12 | |
| *** WadeBerrier[m] <WadeBerrier[m]!wberrierma@2001:470:1af1:104:0:0:0:492d> has quit IRC | 22:13 | |
| *** danigm[m] <danigm[m]!danigmgnom@2001:470:1af1:104:0:0:0:3a57> has quit IRC | 22:13 | |
| *** nanonyme <nanonyme!nanonyme@2001:470:1af1:104:0:0:0:45ea> has quit IRC | 22:13 | |
| *** AdrianVovk[m] <AdrianVovk[m]!adrianvovk@2001:470:1af1:104:0:0:0:2e2a> has quit IRC | 22:13 | |
| *** abderrahim[m] <abderrahim[m]!abderrahim@2001:470:1af1:104:0:0:0:3558> has quit IRC | 22:13 | |
| *** devcurmudgeon[m] <devcurmudgeon[m]!devcurmudg@2001:470:1af1:104:0:0:0:4be6> has quit IRC | 22:13 | |
| *** MatrixTravelerbot[m] <MatrixTravelerbot[m]!voyagert2b@2001:470:1af1:104:0:0:0:2261> has quit IRC | 22:13 | |
| *** SamThursfield[m] <SamThursfield[m]!ssssammatr@2001:470:1af1:104:0:0:0:220c> has quit IRC | 22:13 | |
| *** vchernin[m] <vchernin[m]!vcherninfe@2001:470:1af1:104:0:0:0:49f6> has quit IRC | 22:13 | |
| *** jjardon[m] <jjardon[m]!jjardonmat@2001:470:1af1:104:0:0:0:224c> has joined #buildstream | 22:37 | |
| *** robjh[m] <robjh[m]!~robjhm@2001:470:1af1:104:0:0:0:48ba> has joined #buildstream | 22:37 | |
| *** TheMuso[m] <TheMuso[m]!themuso82m@2001:470:1af1:104:0:0:0:4d68> has joined #buildstream | 22:57 | |
| *** wsalmon[m] <wsalmon[m]!wsalmonmat@2001:470:1af1:104:0:0:0:5c0b> has joined #buildstream | 23:02 | |
| *** danigm[m] <danigm[m]!danigmgnom@2001:470:1af1:104:0:0:0:3a57> has joined #buildstream | 23:05 | |
| *** doras <doras!doras@2001:470:1af1:104:0:0:0:220b> has joined #buildstream | 23:23 | |
| *** JrgBilleter[m] <JrgBilleter[m]!juergbimat@2001:470:1af1:104:0:0:0:6317> has joined #buildstream | 23:25 | |
| *** WadeBerrier[m] <WadeBerrier[m]!wberrierma@2001:470:1af1:104:0:0:0:492d> has joined #buildstream | 23:33 | |
| *** AdrianVovk[m] <AdrianVovk[m]!adrianvovk@2001:470:1af1:104:0:0:0:2e2a> has joined #buildstream | 23:41 | |
| *** nanonyme <nanonyme!nanonyme@2001:470:1af1:104:0:0:0:45ea> has joined #buildstream | 23:42 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!