"bob dev" does not work intuitively with binary artifacts when source comes from tags/commits

[jkloetzke]

When working with "bob dev" the developer expects to be able to change any of the involved sources, call bob again and it will rebuild with the changes. If binary artifacts are used and the sources are deterministic this is not true anymore. The problem is that Bob treats deterministic sources different. For these the actual sources are irrelevant and the binary artifact is downloaded just by looking at the configured tag/commit.

Steps to reproduce with bob-tutorials/binary-repository:

1. bob build --upload root
2. bob dev root/lib/
3. echo "#error" >> dev/src/lib/1/workspace/lib.c
4. bob dev --download=yes root/

Instead of tripping over the #error Bob will happily download the artifact for "root":

$ bob dev --download=yes root/
>> root
   DOWNLOAD  dev/dist/root/1/workspace...ok
Build result is in dev/dist/root/1/workspace

Possible fixes:

1. Don't treat tags/commit special
   This will always checkout all involved sources first, create a hash sum and use that as the access key for the binary artifact. This is already the behavior for checkouts from branches.
   • Pro: consistent definition, will remove special handling of tags/commits, make download decision stateless
   • Con: will download all sources even if not strictly needed, more overhead when building a large tagged software
2. Use current handling of tags/commits and verify that sources are unchanged
   For packages that have their sources checked out it is verified that they were not modified by the user. This validates that the downloaded artifact can be used.
   • Pro: old artifacts are compatible, release mode could stay fast
   • Con: complicated to implement and complicated semantics, download artifacts may be thrown away, requires audit trail
3. Use two build-ids, one for special handling and one for full source hashes
   In release mode Bob could use the current defintion to download artifacts as early as possible. In develop mode Bob could use the source-based build-id to behave like in 1.
   • Pro: Optimal behavior in develop/release mode
   • Con: requires double uploads or symlinks (not possible with webdav), breaks all archive backends, special handling just for release builds from tags