Skip to content

Cache key confusion when elements depend on an open workspace

Summary

If I open a workspace for an element, BuildStream messes up the build of subsequent elements in the pipeline.

Steps to reproduce

Using the example project from https://gitlab.com/valentindavid/org.gnu.Hello/:

  1. bst workspace open hello.bst
  2. bst build org.gnu.Hello.bst
  3. bst checkout org.gnu.Hello.bst

What is the current bug behavior?

BuildStream fails to check out the artifact for org.gnu.Hello.bst with an error like this:

AssertionError: flatpak_image element at org.gnu.Hello.bst [line 1 column 0]: Missing artifact b6790049

If you rerun the bst build command, it will rebuild the artifacts that depend on hello.bst and now, the bst checkout will succeed.

What is the expected correct behavior?

None of the cache keys for hello.bst and beyond can be calculated until hello.bst has been built, but BuildStream currently displays (incorrect) cache keys for these.

Other relevant information

  • BuildStream version affected: 1.1.3+172.g9067e269

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information