Change collect source will cause collect phase to fail

[Robin Winslow]

The "collect" file can pull resources from a few different types of sources. For example, from a Launchpad branch (lp:something) or the charm store (cs:something).

If a charm source changes from one to the other, codetree will no longer know what to do with the old directory in the workspace, and you get an error like this one:

bzr: ERROR: Not a branch: "/srv/mnt/jenkins/srv/mojo/my-project/trusty/ROOTFS/srv/mojo/my-project/trusty/my-workspace/build/haproxy/".
2016-12-01 08:35:09 [ERROR] Codetree: haproxy is not a bzr branch

Mojo should catch this codetree error and clear out erroneous build directories.

[Jacek Nykis (jacekn)]

I think mojo is doing what its supposed to. Codetree call failed so spec run was interrupted.

If you need to move repo you can use "overwrite=True" in the codetree config to allow for that to happen.

[Robin Winslow (nottrobin)]

I think since the mojo workspace is controlled by mojo, mojo should be able to update your build directory to reflect your collect file regardless of what was there before.

Expecting the spec writer to not only be aware of how mojo's workspace is internally managed but also exactly what state the mojo workspace was in previously seems to be exposing the internals of mojo way too much.

In our workflow, we are deploying older versions of specs and then upgrading to newer versions as a matter of course, to test upgrades. In this context, it is extremely likely we'll hit this sort of problem. The *only* way we could achieve it is to just add ";overwrite=True" to every line in our collect file as a matter of course. Indeed, knowing this now I would recommend that everyone using mojo does this all the time.

At that point, I think mojo should have an internal default to overwriting when the collect source has changed.

[Tom Haddon (mthaddon)]

So this is a relatively complicated situation. From a user perspective, I can see that having to add overwrite=True whenever you want to change collect source (rather than just increment a version) is cumbersome.

However, the intention behind this is that we wanted to ensure that it was transparent to both SREs and developers what versions of charms had been deployed at a given time. If we simply changed the location we were pulling from we then lost history. Unfortunately this was never fully implemented as intended in any case, and we're also seeing a lot more changes of charm location (LP -> Charmstore primarily) which mean we should address this in a different way.

As part of other changes in Mojo we're planning to record which versions of charms have been deployed, at which point I agree that we can default to always overwriting charms in the workspace so the operator doesn't have care about whether the source of the charm has changed.