| *** nimish has joined #buildstream | 01:38 | |
| *** alatiera has quit IRC | 02:33 | |
| *** tristan has joined #buildstream | 03:32 | |
| *** nimish has quit IRC | 04:15 | |
| *** nimish has joined #buildstream | 04:16 | |
| *** mohan43u has quit IRC | 04:26 | |
| *** mohan43u has joined #buildstream | 04:27 | |
| *** tristan has quit IRC | 04:51 | |
| *** nimish has quit IRC | 04:53 | |
| *** nimish has joined #buildstream | 04:53 | |
| gitlab-br-bot | tpollard opened MR !1228 (tpollard/fix-complete-nonetype->master: _frontend/cli.py: Don't attempt to path NoneType in complete_target()) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1228 | 05:12 |
|---|---|---|
| *** nimish has quit IRC | 05:26 | |
| *** tpollard has joined #buildstream | 06:06 | |
| *** mohan43u has quit IRC | 06:09 | |
| gitlab-br-bot | tristanvb approved MR !1228 (tpollard/fix-complete-nonetype->master: _frontend/cli.py: Don't attempt to path NoneType in complete_target()) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1228 | 06:10 |
| *** nimish has joined #buildstream | 06:11 | |
| *** tristan has joined #buildstream | 06:13 | |
| *** mohan43u has joined #buildstream | 06:14 | |
| *** nimish has quit IRC | 06:17 | |
| *** mohan43u has quit IRC | 06:33 | |
| gitlab-br-bot | marge-bot123 closed issue #958 (Autocompletion outside of a project produces stack trace) on buildstream https://gitlab.com/BuildStream/buildstream/issues/958 | 06:36 |
| gitlab-br-bot | marge-bot123 merged MR !1228 (tpollard/fix-complete-nonetype->master: _frontend/cli.py: Don't attempt to path NoneType in complete_target()) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1228 | 06:36 |
| *** tristan has quit IRC | 07:31 | |
| *** mohan43u has joined #buildstream | 07:32 | |
| *** tpollard has quit IRC | 07:37 | |
| *** tpollard has joined #buildstream | 07:37 | |
| *** tpollard has quit IRC | 07:44 | |
| gitlab-br-bot | marge-bot123 merged MR !1124 (raoul/440-source-cache->master: Source cache) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1124 | 07:53 |
| *** tpollard has joined #buildstream | 08:36 | |
| *** benschubert has quit IRC | 09:01 | |
| *** benschubert has joined #buildstream | 09:05 | |
| *** toscalix has joined #buildstream | 09:07 | |
| *** toscalix has quit IRC | 09:14 | |
| *** toscalix has joined #buildstream | 09:16 | |
| *** tpollard has quit IRC | 09:25 | |
| *** slaf has quit IRC | 09:29 | |
| *** slaf has joined #buildstream | 09:32 | |
| *** slaf has joined #buildstream | 09:32 | |
| *** slaf has joined #buildstream | 09:33 | |
| *** raoul has joined #buildstream | 09:33 | |
| *** mohan43u has quit IRC | 09:48 | |
| *** mohan43u has joined #buildstream | 09:48 | |
| *** jonathanmaw has joined #buildstream | 10:04 | |
| *** toscalix has quit IRC | 10:32 | |
| *** toscalix has joined #buildstream | 10:32 | |
| *** lachlan has joined #buildstream | 10:38 | |
| phildawson | raoul, I've fixed the commit messages on !1215. Are you happy for me to marge it? | 10:45 |
| raoul | yep go for it :) | 10:45 |
| phildawson | Cheers | 10:46 |
| *** alatiera has joined #buildstream | 10:47 | |
| gitlab-br-bot | marge-bot123 merged MR !1215 (phil/consolidate-repo-tests->master: Consolidate templated source tests) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1215 | 10:52 |
| benschubert | phildawson: :'( soo many conflicts with that | 10:55 |
| phildawson | I know. Rebasing it was a massive pita :/ | 10:56 |
| Kinnison | phildawson: Feh | 10:57 |
| Kinnison | phildawson: You should try rebasing my branch | 10:57 |
| * phildawson is glad to avoid that particular ball of fun | 10:57 | |
| Kinnison | It only touches 90% of anything which ever thinks about yaml | 10:57 |
| benschubert | phildawson: I've got a 26 commits, 55 changes on the tests that were coming, now I need to rebase on yours :'D | 10:57 |
| phildawson | I'm just glad I got in first :P | 10:58 |
| benschubert | 20 commits :D | 10:58 |
| *** lachlan has quit IRC | 11:16 | |
| raoul | juergbi, the more I look into getting the logic in push to work with sources sensibly, the more I think it makes sense to add another queue, any thoughts? Unless I've missed something it doesn't look adding a new queue would be too hard | 11:17 |
| juergbi | raoul: as discussed, separate queue probably makes sense anyway long term | 11:24 |
| juergbi | if it can indeed be done without too much effort, would be great to already fold it into this MR | 11:24 |
| raoul | Cool, shall attempt to do this | 11:24 |
| juergbi | raoul: I suspect the frontend/UI aspect might not be trivial, though | 11:25 |
| juergbi | two queues called 'push' would obviously be confusing | 11:25 |
| raoul | Yeah not sure what to call it, could just be source_push but that might be too long for the UI | 11:26 |
| gitlab-br-bot | juergbi opened MR !1230 (juerg/cas->master: _casbaseddirectory.py: Use variable-length argument list) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1230 | 11:31 |
| *** lachlan has joined #buildstream | 11:37 | |
| Kinnison | benschubert: I've got a 102 commit branch to rebase soon :/ | 11:49 |
| benschubert | 102 commits? Oo | 11:49 |
| *** alatiera has quit IRC | 12:05 | |
| *** alatiera has joined #buildstream | 12:06 | |
| *** alatiera has quit IRC | 12:25 | |
| gitlab-br-bot | marge-bot123 merged MR !1230 (juerg/cas->master: _casbaseddirectory.py: Use variable-length argument list) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1230 | 12:27 |
| *** lachlan has quit IRC | 12:31 | |
| *** raoul has quit IRC | 12:36 | |
| *** alatiera has joined #buildstream | 12:41 | |
| toscalix | This limitation we experience with the website repo and subgroups has been fixed: https://gitlab.com/gitlab-org/gitlab-ce/issues/30548 | 13:08 |
| *** nimish has joined #buildstream | 13:16 | |
| *** raoul has joined #buildstream | 13:24 | |
| *** nimish has quit IRC | 14:04 | |
| Kinnison | Is there a way to know what Marge is doing for an MR? | 14:05 |
| Kinnison | I assigned her an MR which needs rebasing but so far she seems to have been sitting on it | 14:05 |
| *** nimish has joined #buildstream | 14:07 | |
| *** tpollard has joined #buildstream | 14:08 | |
| juergbi | maybe adds68 knows? | 14:10 |
| *** lachlan has joined #buildstream | 14:11 | |
| benschubert | Kinnison: she might have other MRs to rebase first | 14:17 |
| Kinnison | aah | 14:17 |
| Kinnison | OK | 14:17 |
| benschubert | it will go in a fifo and rebase only one at a time :D | 14:17 |
| benschubert | hence not overflowing our builders with useless runs | 14:17 |
| *** lachlan has quit IRC | 14:17 | |
| Kinnison | Looking at https://gitlab.com/BuildStream/buildstream/merge_requests?scope=all&utf8=%E2%9C%93&state=opened&assignee_username=marge-bot123 - she only has the one MR | 14:17 |
| benschubert | then I don't know | 14:17 |
| *** lachlan has joined #buildstream | 14:27 | |
| *** tpollard has quit IRC | 14:29 | |
| *** lachlan has quit IRC | 14:32 | |
| adds68 | Kinnison, as benschubert said :) | 14:32 |
| Kinnison | adds68: so, since she only has the one MR assigned, and it's the one I assigned, what's up? | 14:33 |
| adds68 | Hm, yes i just saw that, i am not sure | 14:33 |
| adds68 | usually if there is a problem she will comment on the MR asking to be fixed | 14:33 |
| Kinnison | there's lots of pipelines running right now I s'pose | 14:34 |
| Kinnison | None mine though :( | 14:34 |
| gitlab-br-bot | mbodmer opened issue #962 (Question: How to have parallel builds for different architectures) on buildstream https://gitlab.com/BuildStream/buildstream/issues/962 | 14:40 |
| Kinnison | She finally rebased it \o/ | 14:41 |
| juergbi | she was just out for lunch? | 14:41 |
| Kinnison | perhaps :D | 14:42 |
| *** lachlan has joined #buildstream | 14:49 | |
| *** lachlan has quit IRC | 14:53 | |
| raoul | juergbi, for !1214 I've now put sources being pushed into a separate pipeline. They also give the status push, but as in the info and finished status it's source push(ed) I think it's clear enough. Still need to add some tests but let me know if you think it's alright (or anyone else that wants to have a look) | 15:03 |
| gitlab-br-bot | MR !1214: Remote source cache https://gitlab.com/BuildStream/buildstream/merge_requests/1214 | 15:03 |
| *** tristan has joined #buildstream | 15:04 | |
| *** tristan has quit IRC | 15:05 | |
| *** lachlan has joined #buildstream | 15:05 | |
| juergbi | raoul: ok, will take a look | 15:16 |
| juergbi | we should probably also add a `bst source push` command, right? | 15:16 |
| juergbi | not a blocker, though, imo | 15:16 |
| raoul | yeah we probably should, can add it to follow up work | 15:26 |
| Kinnison | If I have a bare number in a field (e.g. strip-level: 1) should I expect that track might quote that ('1') ? | 15:29 |
| *** lachlan has quit IRC | 15:31 | |
| *** lachlan has joined #buildstream | 15:37 | |
| juergbi | jonathanmaw: WSL seems to be very slow now | 16:18 |
| juergbi | marge is upset ;) I'm doing a quick manual merge | 16:18 |
| * jonathanmaw pokes WSL to see if something's amiss | 16:19 | |
| juergbi | I haven't seen any hangs but it takes >90 min to complete | 16:20 |
| gitlab-br-bot | juergbi merged MR !1209 (jennis/remove_node_chain_stuff->master: Rip out ChainMap(), node_chain_copy(), node_list_copy()) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1209 | 16:21 |
| jonathanmaw | hmm, seeing a bunch of "Failed to process runner" errors | 16:22 |
| jonathanmaw | and failing to communicate with the job coordinator | 16:23 |
| jonathanmaw | code 403. forbidden? how odd. | 16:23 |
| Kinnison | phildawson: Is there a way to limit tox to only running the internal test suite? I'm not sure much else will run yet on my branch but since I rebased recently I'm getting odd things from it trying to pip install -e | 16:38 |
| juergbi | Kinnison: the fix was merged yesterday evening | 16:46 |
| Kinnison | thanks | 16:47 |
| Kinnison | And now begins conflict'o'rama with my rebase | 16:48 |
| Kinnison | :D | 16:48 |
| Kinnison | I fear this will take some time | 16:51 |
| Kinnison | artifact abstraction, source cache, cas changes, all joyful conflicts | 16:51 |
| *** lachlan has quit IRC | 16:51 | |
| * raoul does not envy Kinnison | 16:53 | |
| Kinnison | Frankly, 'tis basically hometime, I might pretend I've not started this rebase, and go to sleep instead | 16:54 |
| *** toscalix has quit IRC | 16:54 | |
| Kinnison | In fact, I shall | 16:54 |
| benschubert | juergbi: are you around? do you have a minute? I've got question about !1070 and the runtime_cache_key we were speaking about | 17:02 |
| gitlab-br-bot | MR !1070: WIP: Refactor _update_state() to be called only when needed https://gitlab.com/BuildStream/buildstream/merge_requests/1070 | 17:02 |
| juergbi | benschubert: sure | 17:02 |
| benschubert | I was wondering how was the best way of keeping this key up to date. having a "update_runtime_key()" method and split rdeps on whether they are required for (build|all) or only runtime and when only runtime, call the update_runtime_key whenever we do the update_state_recursively? | 17:03 |
| benschubert | juergbi: does this seem sensible? Do you see a better way? | 17:06 |
| juergbi | benschubert: I was originally not thinking about incremental updates | 17:08 |
| juergbi | in most situations, keys don't change later on, they mainly just go from None to the final key | 17:09 |
| juergbi | and thus, if the key is calculated only if all dependencies also have a key, I wouldn't expect the overhead to be very big | 17:09 |
| benschubert | juergbi: so only using the strong_cache_key in case of runtime-only deps? Since this is the only one we need | 17:11 |
| benschubert | so whenever our strong_cache_key gets updated, we go through our runtime_only_rdeps and update the runtime_key, and the normal key of all their rdeps? | 17:12 |
| juergbi | use the strong cache key of the self combined with the runtime key of the runtime dependencies | 17:12 |
| benschubert | juergbi: not sure why we need to combine there? | 17:12 |
| juergbi | that way we'd have a single trigger. that's how I was thinking about it | 17:13 |
| juergbi | not sure whether splitting up would also work without issues | 17:13 |
| juergbi | we definitely need to cover indirect runtime dependencies | 17:13 |
| juergbi | so if we use the combined key, that's definitely covered | 17:13 |
| juergbi | if the two aspects are considered separately, we don't get that for free, afaict | 17:14 |
| benschubert | juergbi: for indirect combined deps, we only care when they are ALL discovered right? So we can set our runtime_deps_resolved to True once all our runtime_deps have it set to true and done no? | 17:14 |
| benschubert | or am I missing something | 17:14 |
| juergbi | yes but then we would still have to recursively check all runtime deps | 17:15 |
| juergbi | I think it would be cheaper to create a combined hash and then only check direct deps | 17:15 |
| benschubert | juergbi: only the direct ones | 17:15 |
| benschubert | and if they don't have this flag to true, it means one of their rdep is not ready | 17:15 |
| juergbi | right, for the check that should suffice | 17:15 |
| juergbi | however, to actually calculate the runtime key, you'd need to recurse, wouldn't you? | 17:16 |
| juergbi | while with a combined key, you can skip the recursion also for the runtime key calculation | 17:16 |
| benschubert | so the algo would be: | 17:17 |
| benschubert | when a strong cache key is discovered, go to all runtime_only reverse dependencies (others are already covered) and for each one do: | 17:17 |
| benschubert | - if all direct runtime deps are ready: update all reverse dependencies keys | 17:17 |
| benschubert | - otherwise pass | 17:17 |
| benschubert | Or am I missing something? | 17:17 |
| juergbi | the runtime key is a hash that includes the runtime dependencies, not the rdeps | 17:18 |
| juergbi | that key is used as a trigger to update rdeps | 17:18 |
| juergbi | but the key itself is of regular deps | 17:18 |
| gitlab-br-bot | marge-bot123 merged MR !1210 (aevri/nodefaultsset->master: element.__init_default: treat `None` plugin_conf as if missing file + refactor) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1210 | 17:19 |
| benschubert | juergbi: so in what case would the above algorithm break? | 17:19 |
| juergbi | when a runtime dependency changes, we may need to update state/keys of reverse dependencies | 17:20 |
| benschubert | yes | 17:20 |
| benschubert | when a runtime dependency has its strong_cache_key change only though correct? | 17:20 |
| juergbi | yes (including indirect runtime dependencies) | 17:21 |
| juergbi | so if a.bst has a key change | 17:22 |
| juergbi | and b.bst is a reverse runtime-only dependency | 17:22 |
| juergbi | b.bst's strong key will not change no matter what happens in a.bst (because it's runtime-only) | 17:23 |
| juergbi | so the algo wouldn't trigger an update in c.bst, which may build depend on b.bst | 17:23 |
| juergbi | i.e., c.bst build-depends on b.bst. b.bst runtime-depends on a.bst | 17:24 |
| juergbi | c.bst's strong key will change when a.bst's strong key changes | 17:24 |
| juergbi | however, b.bst's strong key will not change when a.bst's strong key changes | 17:25 |
| juergbi | or am I misunderstanding your algo? | 17:25 |
| juergbi | (I have my head wrapped around the other algo which works quite differently) | 17:25 |
| benschubert | So: | 17:26 |
| benschubert | 1) store BUILD|ALL direct reverse dependencies in a "reverse_dep_for_build_or_all", and all RUNTIME only direct dependencies in a "reverse_dep_for_run" | 17:26 |
| benschubert | 2) when a strong cache key is discovered for an element, go through all elements in "reverse_dep_for_run". | 17:26 |
| benschubert | - if all direct runtime dependency of this element have a strong_cache_key discovered (not None): | 17:26 |
| benschubert | - update the state of all "reverse_dep_for_build_or_all" | 17:26 |
| benschubert | - if the element has a strong cache key, goto 2 for this element. | 17:26 |
| benschubert | - otherwise, pass | 17:26 |
| benschubert | Is that clearer? | 17:26 |
| juergbi | hm, maybe that would work with the single indirect runtime dependency | 17:27 |
| juergbi | but if we add one additional indirection (c.bst build-depends on b1.bst which runtime-depends on b2.bst which runtime-depends on a.bst), does this still work? | 17:27 |
| juergbi | in case of key change | 17:28 |
| benschubert | So a.bst would get a new strong_cache_key. We would go through the reverse_dep_for_run, that means "b2.bst" only. | 17:30 |
| benschubert | 1) b2.bst doesn't has anything in "reverse_dep_for_build_or_all", so it doesn't do anything there | 17:30 |
| benschubert | 2) two cases: | 17:30 |
| benschubert | 2.1) b2.bst has a strong cache key, we repeat for b1.bst | 17:30 |
| benschubert | 2.2) b2.bst doesn't have a strong cache key, there is no point in updating b1.bst, since b2.bst is not ready | 17:30 |
| benschubert | Does that seem correct to you? | 17:31 |
| juergbi | hm, but then we're essentially going over all reverse dependencies, recursively, even if the key doesn't change in intermediate elements | 17:32 |
| juergbi | as we also have to recurse further for build rdeps | 17:32 |
| benschubert | but that's the case with the hash anyways | 17:33 |
| juergbi | that should work but that's the slower approach | 17:33 |
| juergbi | no, with the hash you only have to go further if the hash changes | 17:33 |
| benschubert | same here, but I only have a boolean | 17:33 |
| juergbi | you have to recurse even if the strong cache key of intermediate elements doesn't change, though | 17:33 |
| juergbi | my scenario was when a.bst's key changes, not when it's initially set | 17:34 |
| benschubert | juergbi: the strong_cache_key never changes once discovered | 17:34 |
| juergbi | ah, we don't set it for workspaces until after assembly? | 17:34 |
| * juergbi forgot the details | 17:35 | |
| benschubert | juergbi: if I understand well https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/element.py#L1227-1238 prevents it right? | 17:36 |
| juergbi | yes, that should be correct | 17:36 |
| benschubert | in that case my version would be simpler and quicker correct? | 17:37 |
| benschubert | and correct too | 17:37 |
| benschubert | juergbi: or do you see something wrong with it? | 17:43 |
| juergbi | "- if all direct runtime dependency of this element have a strong_cache_key discovered (not None):" | 17:43 |
| juergbi | what if an indirect runtime dependency doesn't have a strong cache key yet? | 17:43 |
| juergbi | this might mean that the strong cache key of a reverse build dependency can't be calculated yet | 17:44 |
| juergbi | might this be an issue? | 17:44 |
| benschubert | mmh we would go through everything and we shouldn't true. | 17:44 |
| benschubert | So we need a boolean "ready_for_runtime", that is all(runtime_deps.ready_for_runtime) and self.__strong_cache_key is not None | 17:45 |
| benschubert | correct? | 17:45 |
| juergbi | yes | 17:46 |
| juergbi | in a way it's a 1 bit variant of my combined hash | 17:46 |
| benschubert | agreed | 17:46 |
| benschubert | but reduce the need for hashing :D | 17:46 |
| juergbi | yes, as we don't need to care about hash changes, but only about hash being available | 17:46 |
| benschubert | So you would agree with a variant like that (assuming it does work)? | 17:46 |
| juergbi | we can skip the actual hashing, but conceptually the same algo still makes sense | 17:47 |
| juergbi | probably the most efficient approach | 17:47 |
| juergbi | and hopefully correct ;) | 17:47 |
| benschubert | great! If you think of hard test cases we don't cover in the tests, please let me know so we can add them. I've already got two from Tristan | 17:48 |
| benschubert | I'll implement this today/tomorrow and we should be able to review that soon | 17:48 |
| juergbi | great | 17:48 |
| juergbi | would we still calculate weak cache key early on or also only when deps are ready? | 17:48 |
| benschubert | juergbi: that is a change that jonathanmaw is looking into if I remember well, correct jonathanmaw? | 17:49 |
| jonathanmaw | benschubert: I'm looking into all the stuff _update_state does | 17:50 |
| * jonathanmaw reads backscroll for context | 17:50 | |
| juergbi | benschubert: btw: 'ready_for_runtime' might be a bit misleading as it won't mean that the elements are actually built | 17:51 |
| benschubert | juergbi: it would though, if we incorporate the "__strong_cache_key is not None" in the bool right? | 17:51 |
| juergbi | no, cache key available doesn't mean that the element was built | 17:52 |
| benschubert | juergbi: or we can have "all_runtime_deps_ready", which might be better right? | 17:52 |
| juergbi | for simple cases (strict build plan, no workspace, etc), we can calculate all strong cache keys early on | 17:52 |
| juergbi | without having built anything | 17:52 |
| benschubert | ah gotcha | 17:53 |
| benschubert | so "__runtime_deps_strong_cache_keys_resolved" ? | 17:53 |
| juergbi | I think that would be accurate | 17:54 |
| benschubert | and for the elements needing the current element only at runtime: "__elements_with_dependencies_on_us_at_runtime_only"? It's starting to look like a paragraph but this part of the code is complex | 17:55 |
| * jonathanmaw is not sure whether you only need to worry about the strong cache key when updating reverse-dependencies. Elements with BST_STRICT_REBUILD calculate cache keys based on their dependencies' weak cache keys instead of their names | 17:56 | |
| benschubert | jonathanmaw: we are only looking in the case where this is a dependency for runtime only, which is only taken into account in the strong_cache_key | 17:57 |
| benschubert | afaik | 17:57 |
| juergbi | benschubert: I'd prefer reverse_dependencies to dependencies_on_us. __runtime_only_reverse_dependencies? | 17:57 |
| juergbi | however, should we even separate this and the build reverse dependencies? | 17:58 |
| benschubert | juergbi: we have two types of reverse dependencies, the ones needing us at runtime only, and the ones needing us at build time too. reverse_dependencies would not be enough | 17:58 |
| benschubert | I think that yes | 17:58 |
| benschubert | because for build, there are other moments where we need the weak cache keys no? | 17:58 |
| juergbi | we might not actually need them earlier than when the strong cache key becomes available, in which case trigger on strong cache key / deps setting would suffice | 18:01 |
| juergbi | but I might be missing an aspect here | 18:01 |
| juergbi | it would be a nice simplification, though | 18:02 |
| benschubert | mmh I'm sure something is missing there, but I can try | 18:02 |
| juergbi | it might delay pull attempts of strict artifacts in non-strict mode | 18:06 |
| juergbi | not sure whether that would actually be an issue, though | 18:06 |
| benschubert | so the tests would fail | 18:06 |
| juergbi | I'm not sure | 18:07 |
| juergbi | just different scheduling | 18:07 |
| juergbi | so I wouldn't expect tests to fail | 18:07 |
| juergbi | but I might be missing something | 18:07 |
| *** lachlan has joined #buildstream | 18:07 | |
| benschubert | sure | 18:08 |
| benschubert | I'll try with that, see if tests work | 18:08 |
| juergbi | ok, thanks | 18:09 |
| benschubert | otherwise I'll go with the other solution (keep build deps as we have in !1070 and do what we said for runtime_deps | 18:09 |
| gitlab-br-bot | MR !1070: WIP: Refactor _update_state() to be called only when needed https://gitlab.com/BuildStream/buildstream/merge_requests/1070 | 18:09 |
| benschubert | juergbi: why does the strict_cache_key takes precedence over the strong_cache_key? | 18:15 |
| juergbi | benschubert: in what aspect/situation? | 18:15 |
| *** lachlan has quit IRC | 18:16 | |
| benschubert | we have if context.getstrict(): cache_key = strict; elif _cached(): cache_key = strong_key | 18:16 |
| juergbi | in strict mode, there is no difference anyway | 18:17 |
| juergbi | in non-strict mode, we need to load the strong cache key from the cached artifact, it's impossible to purely calculate it | 18:17 |
| juergbi | (if we're reusing a cached artifact, not building the element) | 18:18 |
| benschubert | oh ok | 18:18 |
| juergbi | i.e., in strict mode, there is exactly one possible strong key and that's the strict key | 18:18 |
| juergbi | in non-strict mode there are arbitrary number of possible strong keys | 18:18 |
| benschubert | but a single strict | 18:18 |
| benschubert | I see | 18:18 |
| juergbi | yes, there is always only a single strict one | 18:19 |
| juergbi | however, the strict one is not relevant in non-strict mode, except when attempting to pull the 'perfect' strict artifact from the artifact server | 18:19 |
| juergbi | (and the same for the check in the local cache first, of course) | 18:19 |
| benschubert | juergbi: so having only the cache_key as a test, test_push_pull_track_non_strict doesn't pass | 18:19 |
| benschubert | so my guess is, it's not possible like that, we need to use the previous iteration | 18:20 |
| *** raoul has quit IRC | 18:20 | |
| juergbi | maybe, I'd have to take a closer look. about to head out now | 18:20 |
| benschubert | ok let's sync tomorrow | 18:20 |
| benschubert | if that's good with you :) | 18:20 |
| juergbi | sure | 18:23 |
| *** nimish has quit IRC | 18:31 | |
| *** nimish has joined #buildstream | 18:31 | |
| *** jonathanmaw has quit IRC | 18:38 | |
| *** alatiera has quit IRC | 19:17 | |
| *** nimish has quit IRC | 19:47 | |
| *** rdale has quit IRC | 20:31 | |
| gitlab-br-bot | juergbi merged MR !1223 (aevri/doc_artifact_log->master: 'artifact log': document the 'artifacts' argument) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1223 | 20:50 |
| *** alatiera has joined #buildstream | 23:16 | |
| *** alatiera has quit IRC | 23:19 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!