Problem Definition

With Bamboo Specs in RSS the diff and caching behaviour can cause a situation that is difficult to understand and recover from.

Example scenario:

1. Repo 1 with Bamboo Spec pointed to PLAN-KEY
2. Accidentally push the same Bamboo Spec pointed to PLAN-KEY to Repo 2 and change the repository in it. Scan this repository. PLAN-KEY now becomes managed by Repo 2.
3. Try to switch PLAN-KEY back to Repo 1 simply by scanning Repo 1 with no changes
4. Bamboo Specs says execution was successful but didn't actually revert it to Repo 1 because as far as the comparison is concerned, there were no changes since the last scan for Repo 1 (but changes were applied by Repo 2)

This can be a confusing behaviour to an end user because they're hitting scan specs and it's saying the execution is successful but there is still a mismatch between spec and plan.

There's no way to recover here without making a change to the Spec in Repo 1 so Bamboo sees a difference and applies it (or going and deleting temporary files related to specs). While this may seem like an easy workaround, some organisations have strict change control and even making a small change to build and deploy configuration requires approvals which complicate recovery.

Suggested Solution

• When a Specs update choose not to make any modifications due to no diff, make it clear in the UI
• Include a force update button that will treat the spec as new / apply it anyway (skip the diff) or enhance the scan to detect that the plan it is updating may have been updated by a different repository.