search

buildstream-migration / bst-staging

GNU Lesser General Public License v2.1
0 stars 0 forks source link

Checkout needs sandbox even when run with --no--intergration #1352

Open Cynical-Optimist opened 3 years ago

Cynical-Optimist commented 3 years ago

See original issue on GitLab In GitLab by [Gitlab user @willsalmon] on Jul 7, 2020, 11:27

Summary

Checkout needs sandbox even when run with --no--intergration

This means that if a project was built in CI on a different arch or with RE and the RE bots are busy, artefacts can not be checked out even if they are just a tar/docker-image/single file.

We could do it with a approach like https://gitlab.com/BuildStream/buildstream/-/merge_requests/1983 or we tweak how the sandbox is invoked so that it dose not need a real sandbox.

Cynical-Optimist commented 3 years ago

In GitLab by [Gitlab user @cs-shadow] on Jul 14, 2020, 22:02

I'm not sure if I follow. This is already possible, and precisely the reason we have the dummy sandbox (SandboxDummy). This should be automatically get created when buildbox-run isn't available for whatever reason.

If this is not happening, this would be a bug in BuildStream. If so, please share more details about it, and how to reproduce it.

Cynical-Optimist commented 3 years ago

In GitLab by [Gitlab user @willsalmon] on Jul 15, 2020, 10:51

For this case buildbox-run is available but dose not support the target arch.

The element was made by using remote exicution or CI with a different arch. by setting the sandbox arch you can get the right cache key and pull down the artefact. But when you try to check it out then the sandbox dose not create a dummy but complains that the arch is not supported for a full sandbox.

This makes seance when --no-intergration is not used but dose not make sense if --no-intergration is specified.

Cynical-Optimist commented 3 years ago

In GitLab by [Gitlab user @cs-shadow] on Jul 15, 2020, 11:03

Thanks. I think the fix in that case should be to ensure that we do use the dummy sandbox in such code paths, rather than circumventing that in places other than the sandbox module. This keeps all related logic in one place and avoids unncessary forks in the code.

Cynical-Optimist commented 3 years ago

In GitLab by [Gitlab user @cs-shadow] on Jul 15, 2020, 11:04

mentioned in merge request !1983

Cynical-Optimist commented 3 years ago

In GitLab by [Gitlab user @willsalmon] on Jul 15, 2020, 13:49

The issue that i had was that AFAICT we pick which sandbox to use for the run really early, at the platform level so you lose the chance to fall back at the point were we actually invoke it. Im not sure if that's true but that's what it looked like when I looked. Duno if [Gitlab user @cs-shadow] or [Gitlab user @juergbi] can point me in the right direction for how to fix this sensibly.