| *** mohan43u has joined #buildstream | 01:30 | |
| juergbi | devcurmudgeon: 1.9x.x are development snapshots leading up to the 2.0 release. the min-version approach can only work properly within a stable release series, which will start again with 2.0 | 04:31 |
|---|---|---|
| juergbi | the .bst format itself should be almost fully compatible. what issues do you see? | 04:33 |
| juergbi | plugin code and small parts of project.conf need migration | 04:34 |
| *** tristan has quit IRC | 06:08 | |
| *** tristan has joined #buildstream | 06:18 | |
| juergbi | jjardon: the permanent runners are filling up on disk space, mainly in /var/lib/docker/volumes, resulting in CI failures | 06:43 |
| gitlab-br-bot | marge-bot123 merged MR !1887 (juerg/vdirectory->master: Require virtual directory support for element plugins) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/1887 | 06:44 |
| juergbi | do you know how we can handle cleanup of that? `docker volume ls` doesn't show any dangling volumes, so `docker volume prune` doesn't remove anything. although, `docker container ls` doesn't show any running containers right now... | 06:44 |
| juergbi | the bastion autoscale runners seem to work fine right now. wondering whether it would make more sense to go for 4 bastions with the low max. machine limit each | 06:47 |
| *** ChanServ sets mode: +o tristan | 06:52 | |
| tristan | juergbi, maybe it's the "cache" ? | 06:53 |
| tristan | as I recall those things gradually just grow | 06:53 |
| tristan | dont know how it's implemented dockerwise, but perhaps it's a volume | 06:53 |
| juergbi | it's much more than that. I see .tox directories from failed tests | 06:53 |
| juergbi | using up a lot of space | 06:53 |
| juergbi | the runner cache might indeed also be there. I'm not sure how exactly gitlab runner manages docker volumes/containers | 06:54 |
| tristan | maybe those are intentionally kept around by gitlab ? (do we keep around gitlab artifacts of builds which fail ? I think that's an option) | 06:55 |
| tristan | not sure why we would have .tox directories in artifacts though | 06:55 |
| gitlab-br-bot | juergbi opened MR !1888 (juerg/sandbox->master: Switch preferred sandbox from bwrap to buildbox-run) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/1888 | 06:57 |
| juergbi | tristan: it seems it's keeping around the whole volume of the executed job, which happens to include the .tox directory. not just the job artifacts | 06:57 |
| juergbi | don't know whether that's intentional for failed jobs | 06:58 |
| tristan | yeah I can see why that would be useful | 06:59 |
| * tristan comes across https://gitlab.com/gitlab-org/gitlab-runner-docker-cleanup/-/issues/10 and https://gitlab.com/gitlab-org/gitlab-runner/-/issues/1611 which might be useful | 07:01 | |
| juergbi | will take a look | 07:01 |
| juergbi | tristan: can you please take a quick look at https://gitlab.com/BuildStream/website/-/merge_requests/135 ? | 07:01 |
| tristan | the second one appears to have to do with dangling volumes which apparently we dont have | 07:02 |
| tristan | oh yeah that one... | 07:02 |
| juergbi | which still seems a bit confusing to me as docker claims the definition of a dangling volume is one that is not used by any containers | 07:02 |
| juergbi | however, as `docker container ls` returned no containers at all at that point, how can any volume _not_ be dangling? | 07:03 |
| juergbi | ah, it by default only shows running containers but there are lots of stopped containers | 07:04 |
| juergbi | so it seems gitlab doesn't always remove stopped containers | 07:04 |
| tristan | you can also query for "exited" containers | 07:06 |
| tristan | right | 07:06 |
| tristan | I recall that I had a script somewhere for this (other laptop unfortunately), but essentially you can find all exited containers and remove them, which frees up references to images which can also be removed | 07:07 |
| tristan | juergbi, I was sort of expecting gitlab to "just get it right" here though | 07:07 |
| juergbi | yes, I think running `docker container prune` followed by `docker volume prune` works | 07:08 |
| tristan | There is also a `docker run` flag, which can be encoded into the image itself I think, which informs docker to remove the container automatically once it has exited | 07:08 |
| juergbi | ok, maybe there is a gitlab runner flag for this | 07:09 |
| traveltissues | juergbi: are there some expected failures on the new buildbox-run? `FAILURE tar-test.bst: You can't use get_directory` | 07:10 |
| tristan | juergbi, for the docs MR, I recall looking at it and didn't comment in the end, I just added the comment I was going to make yesterday | 07:11 |
| juergbi | traveltissues: shouldn't be the case anymore in master but was for a short time while the corresponding plugin MRs were pending | 07:11 |
| juergbi | you may want to rebase | 07:11 |
| tristan | Maybe buildbox-run-bubblewrap is actually a binary and not the build directory | 07:11 |
| juergbi | tristan: yes, it is | 07:12 |
| traveltissues | ah, that would be the issue | 07:12 |
| juergbi | tristan: buildstream simply looks for buildbox-run as it doesn't know which implementation you want to use on the system | 07:12 |
| tristan | Hmmm | 07:12 |
| tristan | I guess that needs sorting out in some other way on the distro (debian "alternatives" or suchlike ?) | 07:13 |
| tristan | anyway, leave it for another day | 07:13 |
| juergbi | tristan: yes. for regular local builds on linux distros you always want buildbox-run-bubblewrap. however, there could be some more interesting backends also on linux, e.g., there could be one that executes in qemu or similar | 07:14 |
| juergbi | in that case something like debian alternatives will be useful | 07:15 |
| tristan | this pip plugin origin testing is... a lot of code, and I cannot just reuse tests/testutils/python_repo.py (which incidentally is only used by one test) | 07:16 |
| juergbi | :-/ | 07:18 |
| tristan | it's a lot of random information to digest, and our plugin structure is fairly custom | 07:19 |
| tristan | Well, on with the tedious process of learning a lot of information about pypi structure which I will want to forget at the first opportunity :) | 07:20 |
| tristan | Wait, is this even going to work ? Interesting... am I allowed to install a plugin into the active python environment while running a test ? | 07:22 |
| tristan | How does one test the loading process of a plugin from pip, otherwise ? | 07:22 |
| juergbi | I'm not familiar with these details either | 07:23 |
| tristan | yeah, I'd really like to have a test which tests all the wrong behaviors we could have with malformed python packages which purport to provide BuildStream plugins | 07:24 |
| tristan | provide decent error messages etc | 07:24 |
| juergbi | yes, would definitely be great | 07:26 |
| tristan | I'll finish up the branch as is, without the additional explicit support for versioning constraints on pip provided plugin packages, and try to raise the question when cs-shadow comes around (or on the list) | 07:26 |
| juergbi | now can't push to or fetch from gitlab anymore... | 07:27 |
| tristan | I first needed it in order to test version mismatches and figure out the edge cases of version constraints | 07:27 |
| gitlab-br-bot | juergbi closed issue #1262 (Require virtual directory support for element plugins) on buildstream https://gitlab.com/BuildStream/buildstream/-/issues/1262 | 07:36 |
| *** rdale has joined #buildstream | 07:40 | |
| *** benschubert has joined #buildstream | 07:41 | |
| *** jude has joined #buildstream | 07:47 | |
| devcurmudgeon | juergbi: what i see is the missing "min-version", then "Error loading project: /src/project.conf [line 5 column 16]: Unexpected key: format-version" | 07:52 |
| juergbi | devcurmudgeon: right, that's an intentional difference such that buildstream can distinguish between bst 1.x and bst 2.x projects | 07:53 |
| devcurmudgeon | then more things. but both of those could trivially be resolved by code, rather than making a papercut for users | 07:53 |
| juergbi | this was recently discussed on the mailing list | 07:53 |
| juergbi | the error message should be more friendly, though, tristan ^^ | 07:53 |
| juergbi | what you want instead of the format-version line is: | 07:54 |
| juergbi | min-version: 2.0 | 07:54 |
| devcurmudgeon | i know. | 07:54 |
| devcurmudgeon | this is a philosophical point... why expressly break this and force the user to make manual changes? | 07:54 |
| juergbi | buildstream projects are not 100% compatible between 1.x and 2.x | 07:55 |
| gitlab-br-bot | BenjaminSchubert opened issue #1295 (Specifying `command-subdir` doesn't change the element's cache key) on buildstream https://gitlab.com/BuildStream/buildstream/-/issues/1295 | 07:55 |
| devcurmudgeon | i know that also. that doesn't justify this kind of breakage imo | 07:55 |
| juergbi | so we need a way to distinguish between them. and we should report an understandable message in both buildstream release series | 07:55 |
| juergbi | devcurmudgeon: what are you suggesting instead? how to deal with not 100% compatible projects? | 07:56 |
| devcurmudgeon | format-version could have been used for that? | 07:56 |
| tristan | juergbi, I originally had a second check in place for format-version in the first iteration in order to detect BuildStream 1 projects, but found that was redundant with the check for a missing "min-version" | 07:56 |
| tristan | Ah, ok this is a different conversation I walked into | 07:56 |
| juergbi | devcurmudgeon: format-version was a linear format number distinct from the buildstream release version numbering. we thought that it would be easier for users to only have one versioning scheme | 07:57 |
| devcurmudgeon | it's a continuation of conversations from years ago... i'm like a stuck record | 07:57 |
| tristan | At this point BuildStream 2 and BuildStream 1 are not expected in any way to work together | 07:57 |
| tristan | A conversion could be conceivable, a porting guide will be a hard requirement | 07:57 |
| tristan | This is kind of the road we started onto a couple of years ago when we broke API | 07:58 |
| devcurmudgeon | i disagree, but you know that already :) | 07:59 |
| * tristan would have been happy not breaking API at all too, but most people disagreed with me :) | 07:59 | |
| traveltissues | can the format-version key not just be backported so it at least avoids that error? i stumbled on that one too | 07:59 |
| tristan | traveltissues, backport to BuildStream 1 is also planned if that's what you mean | 08:00 |
| traveltissues | ok, good | 08:00 |
| tristan | traveltissues, both tools need to be updated to ensure a clear error happens when users mixup tools/formats | 08:00 |
| juergbi | devcurmudgeon: if you're saying there should essentially never have been a bst 2.0 (i.e., it should still be fully compatible), that was decided a long time ago, and I don't see how discussing past decisions helps | 08:02 |
| juergbi | the goal for 2.x is to stay fully backward compatible for a very long time | 08:02 |
| juergbi | i.e., such a break should definitely be a big exception | 08:04 |
| *** seanborg has joined #buildstream | 08:05 | |
| devcurmudgeon | i'm not discussing past decisions. i've flagged a specific breakage which afaict would have been easily avoidable at the cost of a small amount of ugly code | 08:05 |
| juergbi | I don't think it's about the small amount of ugly code. the idea is that we intentionally want to avoid loading bst 1.x projects because we know they will not work as is with master and vice versus | 08:06 |
| juergbi | the error message should be clear about this, though, if it isn't yet | 08:07 |
| juergbi | and it might indeed make sense to provide some conversion tooling | 08:07 |
| juergbi | i.e., if we don't refuse to load bst 1.x projects, users might get more confusing error messages because of the incompatibility | 08:09 |
| devcurmudgeon | my philosophical point is that every time we break a promise like this, our claim that we won't break it again is less believable | 08:18 |
| devcurmudgeon | as for the specifics here, i don't know what the real difference is between min-version and format-version, but i think it would have been possible to stick with the original key, rather than changing it, and using the bump itself to trigger whatever error, or warning, or conversion. | 08:19 |
| juergbi | I can certainly understand that point. however, from the point of a view of someone that uses stable buildstream releases, there will be "only" one break, from 1.x to 2.0 | 08:23 |
| *** phildawson has joined #buildstream | 08:23 | |
| juergbi | clearly specifying in each project whether it's compatible with bst 1.x or bst 2.x still makes sense to me | 08:23 |
| devcurmudgeon | i assume that the real incompatibilities are much more fundamental than this. what is the actual plan for helping 1.x users to cross the chasm? | 08:23 |
| devcurmudgeon | or is the expectation to keep them at 1.x? | 08:24 |
| juergbi | the main incompatibilities are on the plugin API side, so it depends if they developed their own plugins or now | 08:24 |
| juergbi | in the .bst format the incompatibilities are minimal | 08:25 |
| juergbi | (e.g., bst2 branch of freedesktop-sdk doesn't require any .bst file changes) | 08:25 |
| devcurmudgeon | that can't be true... given this format-version key thing :) | 08:25 |
| juergbi | small project.conf changes are required. project.conf is not a .bst file ;) | 08:25 |
| devcurmudgeon | ah, ok | 08:26 |
| juergbi | also the changes in project.conf should be minimal. there will be some changes in plugin loading | 08:26 |
| juergbi | but the bulk is really about switching to plugin versions that are compatible with bst 2.x | 08:27 |
| *** tpollard has joined #buildstream | 08:27 | |
| juergbi | for buildstream projects that use plugins maintained by the BuildStream team, the upgrade should be fairly painless | 08:28 |
| juergbi | for others we'll need a good migration guide | 08:28 |
| devcurmudgeon | in which case why not force the incompatibility warnings/conversion/etc into the plugins, rather than making bst itself incompatible? | 08:28 |
| devcurmudgeon | bst could error saying "you have an incompatible plugin" or not | 08:29 |
| benschubert | The reason why plugins are incompatible is because of changes made in the core | 08:29 |
| juergbi | right, we're planning that as well. tristan has already prepared changes for that | 08:29 |
| devcurmudgeon | ok, i'll stop now :-) | 08:30 |
| *** tristan has quit IRC | 08:30 | |
| juergbi | devcurmudgeon: e.g., BuildStream 1.x core supplied various plugins which we've moved out of core for 2.x | 08:30 |
| juergbi | this requires additions to project.conf | 08:31 |
| juergbi | otherwise BuildStream 2.x users would get a plugin not found error message | 08:31 |
| juergbi | clearly stating which project is 2.x and which isn't, should hopefully provide a better user experience than not doing that | 08:31 |
| juergbi | having the project maintainer change one line to mark the project as a 2.x project should really not be the issue, imo, and we could indeed provide a tool for that | 08:32 |
| juergbi | I'd agree with you if no other project.conf changes were necessary, i.e., if we broke compatibility for no reason | 08:33 |
| juergbi | but as project.conf changes are anyway required, I still think our chosen approach makes sense | 08:33 |
| *** santi has joined #buildstream | 08:34 | |
| juergbi | tl;dr: +1 for a conversion tool for project.conf (ideally also updating plugin sources to 2.x compatible ones) and better error messages | 08:34 |
| devcurmudgeon | could bst init be made re-runnable, and used to fix up project.conf and any other incompatibilities it might find? | 08:37 |
| devcurmudgeon | also, could it write all default configurations into the file, with documentation? | 08:38 |
| juergbi | using bst init for this sounds reasonable to me | 08:38 |
| juergbi | copying the default config incl. documentation could be useful | 08:40 |
| devcurmudgeon | is bst init the only code that writes to project.conf currently? | 08:40 |
| juergbi | however, not sure whether we can do the latter reasonably well for upgrades | 08:40 |
| juergbi | should be easy enough for new projects, though | 08:40 |
| juergbi | I think bst init is the only one that writes to project.conf, yes, but have to check | 08:41 |
| devcurmudgeon | for the upgrade case it could fix up stuff where it can, and output a list if things it can't fix, and provide instructions | 08:42 |
| juergbi | yes, that would be nice | 08:42 |
| devcurmudgeon | shall i raise an issue for this? | 08:44 |
| devcurmudgeon | i'll do that | 08:46 |
| benschubert | Wondering wether a `bst migrate` be more discoverable? | 08:47 |
| *** tristan has joined #buildstream | 08:49 | |
| *** ChanServ sets mode: +o tristan | 08:49 | |
| gitlab-br-bot | devcurmudgeon opened issue #1296 (Improve `bst init`, including 2.x upgrade assistance) on buildstream https://gitlab.com/BuildStream/buildstream/-/issues/1296 | 08:52 |
| juergbi | benschubert: maybe but we should provide a hint to the right command in the corresponding format/min-version error message anyway, so it might not matter too much | 08:53 |
| *** lachlan has joined #buildstream | 09:03 | |
| benschubert | juergbi: true, as long as it's an explicit flag and we don't try to do things on 'bst init' :) | 09:04 |
| WSalmon | Sooo i think this is how cs-shaddow wanted me to install git-lfs, i followed the same patten as the variables do but gitlab thinks I have bad syntax, can anyone spot what i have done wrong? https://gitlab.com/BuildStream/bst-plugins-experimental/-/commit/433805d8eb0a87e7a31b29a1c44f3ad099bfe00d | 09:06 |
| WSalmon | the linter gives `(<unknown>): did not find expected '-' indicator while parsing a block collection at line 48 column 5` but as far as i can tell there is a dash at line 48.. | 09:07 |
| benschubert | WSalmon: <<: *test-script | 09:08 |
| benschubert | you are trying to merge a dict and an array? | 09:08 |
| benschubert | yaml only supports merging dicts, not arrays | 09:08 |
| *** lachlan has quit IRC | 09:08 | |
| WSalmon | i think i am trying to prepend some items to a array | 09:09 |
| benschubert | you can't in yaml | 09:09 |
| benschubert | https://github.com/yaml/yaml/issues/35 | 09:10 |
| WSalmon | then i dont really know how to do this without just re implementing all of script for every block | 09:10 |
| WSalmon | that seems less easy to maintain | 09:10 |
| benschubert | Use `before_script` ? | 09:11 |
| WSalmon | same issue | 09:11 |
| WSalmon | its alread defined | 09:11 |
| WSalmon | gues i could move that in to the template | 09:12 |
| juergbi | benschubert: default bst init operation is interactive, so supporting interactive upgrade seems reasonable to me | 09:12 |
| WSalmon | then use before script in each job | 09:12 |
| benschubert | juergbi: will muddy the waters for https://gitlab.com/BuildStream/buildstream/-/blob/master/src/buildstream/_frontend/app.py#L390 :) | 09:14 |
| juergbi | in interactive mode I don't see this as an issue | 09:15 |
| juergbi | for non-interactive mode we should definitely not upgrade without explicit flag | 09:15 |
| juergbi | should be easy enough to distinguish between bst 1.x and bst 2.x project.conf already existing | 09:16 |
| benschubert | right | 09:16 |
| benschubert | ok seems good then | 09:16 |
| *** lachlan has joined #buildstream | 09:23 | |
| *** lachlan has quit IRC | 09:27 | |
| *** lachlan has joined #buildstream | 09:40 | |
| jjardon | juergbi: paused permanent runners until benbrown or anyone from the infra team can take a look | 09:46 |
| juergbi | jjardon: ok. I think manually running `docker container prune` and `docker volume prune` helps but we obviously don't want to manually do this all the time. a cron job might work but better to have a root fix | 09:48 |
| benbrown | jjardon: Feel like I'm missing some context, oh, disk filling up with docker images? | 09:49 |
| jjardon | I think so, yes | 09:51 |
| WSalmon | uff, we are making progress on getting some shiny new CI but its a bit of a slow burner... cphang ^ | 09:53 |
| tristan | What's the latest on requiring sprinklings of __init__.py files all over the test directories for dummy plugins and avoiding name clashes with pytest's assumption that "every .py file must be loaded in the same namespace" ? | 09:54 |
| tristan | Is there some whitelist I should extend to exclude my test plugins ? or do I still need to sprinkle __init__.py files all over the directories ? | 09:55 |
| *** lachlan has quit IRC | 09:59 | |
| *** narispo has quit IRC | 09:59 | |
| *** narispo has joined #buildstream | 09:59 | |
| cphang | WSalmon jjardon so aiui we have https://gitlab.com/BuildStream/infrastructure/docker-machine-install-role to install docker machine, but we don't have a gitlab runner yet to act as a bastion to dispatch jobs to cloud resources? Is that correct? | 10:05 |
| tristan | Ah, it was norecursedirs in [tool:pytest] in setup.cfg | 10:05 |
| * tristan knew there was something to avoid that | 10:05 | |
| cphang | If so, libreML has a bastion for GCP resources that is in a ansible playbook, it probably won't take too much work to adapt to AWS | 10:06 |
| WSalmon | cphang, also DO broke the DO driver again by lowering there API limits again | 10:07 |
| juergbi | switching from docker-machine to kubernetes might be the best long term solution | 10:07 |
| juergbi | I think gitlab is recommending that, jjardon? | 10:07 |
| WSalmon | and Do removed there aarch64 runners and they dont have windows | 10:08 |
| WSalmon | my gut is using a cloud provider that have arm and windows and a sensible api would be good.. | 10:08 |
| cphang | We can do that with kubernetes as well WSalmon, it's more work, but probably more sustainable long term | 10:09 |
| WSalmon | the DO kubernetes offering is not very cost effective i think we would need to do our own auto scaling if we stuck there | 10:09 |
| cphang | jjardon infrastrcuture declarations for aws kubernetes clusters can be used be lightly adapting https://gitlab.com/celduin/infrastructure/celduin-infra/-/blob/master/terraform/public.tf.jsonnet | 10:10 |
| cphang | juergbi ^ | 10:10 |
| cphang | then sticking arm64 runners and windows machines to the cluster. That will take a bit more work, but not that much. | 10:11 |
| cphang | I think from that point on kubernetes should be able to do the rest. | 10:11 |
| cphang | s/kubernetes/gitlab | 10:11 |
| WSalmon | i have not had a chance to sort out the aws acount stuff cphang :( | 10:12 |
| cphang | WSalmon np :) | 10:12 |
| benbrown | cphang, WSalmon, jjardon: Apologies for not having something sorted by now, here's the current state of my branch: https://gitlab.com/BuildStream/infrastructure/infrastructure/-/commit/d2dccad6f38b654ec1b7535127220b3b750022c2 | 10:17 |
| benbrown | I haven't dug into kubernetes too much myself, but I agree it would be best for the long-term | 10:17 |
| *** lachlan has joined #buildstream | 10:23 | |
| *** lachlan has quit IRC | 10:27 | |
| tristan | So BST_VIRTUAL_DIRECTORY is now removed from plugin.py ? | 11:08 |
| tristan | We appear to still have a bunch of references in bst-plugins-experimental, not pressing | 11:08 |
| * tristan just did a run through of those plugins for his branch | 11:08 | |
| *** lachlan has joined #buildstream | 11:10 | |
| juergbi | tristan: yes, removed from master as no other plugins are supported now | 11:11 |
| juergbi | bst-plugins-experimental still has it as it depends only on 1.93.2, which was still before dropping support for old plugins | 11:11 |
| tristan | Ahaaaaa so now I'm confused | 11:11 |
| juergbi | the extra definition shouldn't hurt on master | 11:11 |
| tristan | Why did I just update bst-plugins-experimental ? It seems I need to do that to pass my tests | 11:12 |
| tristan | ok ok I think I got it | 11:12 |
| juergbi | ah, tox.ini in bst master still references the old bst-plugins-experimental | 11:12 |
| tristan | So, !1885 is marked WIP (because of a `tox.ini` commit) but is otherwise ready for review | 11:13 |
| gitlab-br-bot | MR !1885: WIP: Plugin loading refactor, removing all versioning https://gitlab.com/BuildStream/buildstream/-/merge_requests/1885 | 11:13 |
| *** rdale_ct has joined #buildstream | 11:13 | |
| tristan | it passes when setting tox.ini in BuildStream to the git sha of this bst-plugins-experimental MR: https://gitlab.com/BuildStream/bst-plugins-experimental/-/merge_requests/100 | 11:13 |
| tristan | 100 !!!! | 11:13 |
| tristan | ding ding ding ! | 11:14 |
| juergbi | tristan: it probably makes sense to 'release' bst-plugins-experimental 1.93.2 with the vdirectory ports and the min-version | 11:14 |
| tristan | Yeah | 11:14 |
| juergbi | requires setting the version number in at least one file, not just a tag | 11:14 |
| juergbi | to make sure pip upload works | 11:14 |
| tristan | So my thinking is merge the bst-plguins-experimental branch and release, and then change the tox.ini in my branch, and then merge my branch | 11:15 |
| tristan | I see | 11:15 |
| juergbi | yep, I think that makes sense | 11:15 |
| tristan | But I would still appreciate a review of !1885 :) | 11:15 |
| juergbi | yep, will take a look | 11:15 |
| tristan | its got a refactor or PluginOrigin in there | 11:16 |
| *** rdale has quit IRC | 11:16 | |
| tristan | less dict wrangling and a bit more character, all the plugincontext, origin wrangling/parsing and element/source factories is now in buildstream._pluginfactory | 11:16 |
| * tristan renames the MR | 11:18 | |
| tristan | juergbi, the main thing about this MR is that it does *not* implement the pip version guards as we discussed with cs-shadow (yet) | 11:18 |
| tristan | I figured it made sense to split this up and work on that separately | 11:18 |
| tristan | This one removes BST_FORMAT_VERSION, BST_REQUIRED_VERSION_[MAJOR/MINOR] from plugins, and adds/implements BST_MIN_VERSION | 11:19 |
| juergbi | tristan: right. one concern in this regard is that this requires 2 project.conf migration steps for projects following bst master and using pip origin, right? | 11:20 |
| tristan | It might | 11:20 |
| tristan | juergbi, it would of course only require two steps if you happen to be following bleeding edge very closely | 11:21 |
| juergbi | yes, depends on when exactly the follow up MR arrives | 11:22 |
| tristan | However I should say, right now we don't have versioning constraints on the pip packages we load, that is not necessarily a breaking change | 11:22 |
| tristan | I expect to work on it next | 11:22 |
| juergbi | ah, right | 11:22 |
| juergbi | then it sounds fine to me | 11:22 |
| *** lachlan has quit IRC | 11:22 | |
| tristan | Now, cs-shadow ran a test locally saying that he didnt need to change anything and that specifying 'foo >= 1.2.3' "just worked" (with an ugly stack trace we could handle) | 11:23 |
| tristan | But I have doubts we would want to implement it just like that | 11:23 |
| tristan | it would present some ambiguity about that statement and which package we want to load plugins from | 11:23 |
| tristan | (I guess you would be allowed to also specify 'foo >= 1.2.3, bar <= 4.0' or such craziness | 11:24 |
| tristan | ) | 11:24 |
| juergbi | don't have an opinion on that right now, have to take a closer look | 11:24 |
| tristan | yeah, I want to touch base with cs-shadow before proceeding | 11:24 |
| tristan | But in any of these cases, adding the version checks should be an extension and not a break | 11:24 |
| juergbi | yes, that sounds good. so the second step of adding a version constraint is optional, not breaking | 11:26 |
| tristan | correct | 11:26 |
| tristan | I think my preference will be an added key to the pip origin, but want to discuss with cs-shadow, who said that simply specifying the package name with constraints "also happens to just work" | 11:27 |
| tristan | but either is non-breaking | 11:27 |
| *** lachlan has joined #buildstream | 11:39 | |
| *** lachlan has quit IRC | 11:43 | |
| * tristan thinks it's time to branch 1.4 and start on 1.6 | 12:13 | |
| traveltissues | can i get a review please: https://gitlab.com/BuildStream/bst-plugins-experimental/-/merge_requests/91# | 12:23 |
| *** tristan has quit IRC | 12:50 | |
| *** lachlan has joined #buildstream | 13:24 | |
| *** seanborg_ has joined #buildstream | 13:49 | |
| *** seanborg has quit IRC | 13:49 | |
| *** lachlan has quit IRC | 13:53 | |
| *** lachlan has joined #buildstream | 14:07 | |
| *** lachlan has quit IRC | 14:10 | |
| *** lachlan has joined #buildstream | 14:24 | |
| gitlab-br-bot | coldtom opened issue #1297 (Allow elements/artifacts/parts of artifacts to not be cached remotely) on buildstream https://gitlab.com/BuildStream/buildstream/-/issues/1297 | 14:27 |
| *** lachlan has quit IRC | 14:28 | |
| *** CTtpollard has joined #buildstream | 14:38 | |
| *** tpollard has quit IRC | 14:39 | |
| *** lachlan has joined #buildstream | 14:48 | |
| *** lachlan has quit IRC | 14:53 | |
| *** lachlan has joined #buildstream | 15:14 | |
| WSalmon | I think this is how cs-shaddow wanted the CI doing https://gitlab.com/BuildStream/bst-external/-/merge_requests/119 | 15:17 |
| WSalmon | oh flip, ignore the above | 15:17 |
| WSalmon | I think this is how cs-shaddow wanted the CI doing https://gitlab.com/BuildStream/bst-plugins-experimental/-/merge_requests/101 <- this is what i meant | 15:18 |
| *** lachlan has quit IRC | 15:21 | |
| WSalmon | valentind, ^ | 15:47 |
| *** tristan has joined #buildstream | 15:50 | |
| *** seanborg_ has quit IRC | 16:07 | |
| *** lachlan has joined #buildstream | 16:34 | |
| *** santi has quit IRC | 17:12 | |
| *** lachlan has quit IRC | 17:13 | |
| gitlab-br-bot | chiaratolentino opened MR !1889 (ctolentino/casd-timeout->master: Relax buildbox-casd timeout) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/1889 | 17:28 |
| *** Ariana4924 has joined #buildstream | 17:43 | |
| *** CTtpollard has quit IRC | 17:45 | |
| *** Ariana4924 has quit IRC | 17:45 | |
| *** lachlan has joined #buildstream | 17:57 | |
| *** lachlan has quit IRC | 18:02 | |
| *** Aaliyah6444 has joined #buildstream | 18:15 | |
| *** phoenix has joined #buildstream | 18:16 | |
| *** Aaliyah6444 has quit IRC | 18:19 | |
| gitlab-br-bot | juergbi opened (was WIP) MR !1888 (juerg/sandbox->master: Switch preferred sandbox from bwrap to buildbox-run) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/1888 | 18:29 |
| *** toscalix has joined #buildstream | 18:51 | |
| *** benschubert has quit IRC | 19:37 | |
| *** phoenix has quit IRC | 19:42 | |
| *** phildawson has quit IRC | 20:08 | |
| *** phoenix has joined #buildstream | 20:11 | |
| gitlab-br-bot | cs-shadow opened MR !1890 (chandan/build-shell-fetch->master: _stream.py: Fetch sources while launching build shells) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/1890 | 20:23 |
| gitlab-br-bot | cs-shadow approved MR !1888 (juerg/sandbox->master: Switch preferred sandbox from bwrap to buildbox-run) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/1888 | 20:25 |
| *** jude has quit IRC | 20:43 | |
| *** phoenix has quit IRC | 20:53 | |
| *** toscalix has quit IRC | 21:11 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!