Issue Summary

When setting up a variable for the master-branch in YAML specs and making a commit in the repository, the build fails to kick off automatically, and there's no error message to clue you in on what went wrong.

Steps to Reproduce

1. Set up a YAML specs, using a variable for the master-branch, and assign it any value.
2. Make a commit on the master branch.

Expected Results

Ideally, the build should kick off without a hitch, or if there's a snag, it should throw up an error message similar to what you get when there's an issue with the name parameter. For instance, the logs might show something like this:

 30-May-2024 13:10:42	Bamboo YAML import failed: A plan name cannot contain a [, ], {, }, <, >, :, @, /, &, %, \, !, |, #, $, *, ;, ', " or ~ character.
30-May-2024 13:10:42	
30-May-2024 13:10:42	
30-May-2024 13:10:42	Need a hand? Check out http://docs.atlassian.com/bamboo/docs-0904/Bamboo+Specs+troubleshooting
30-May-2024 13:10:42	

But when the snag is with the master-branch variable, the build just stalls out without any error message.

Actual Results

The build doesn't get off the ground, and you're left in the dark with no error message.

2024-05-10 17:46:17,636 INFO [15-BAM::SpecsDetection:pool-20-thread-4] [GitBambooSpecsHandler] Commit 4691df656a2ddd3f36ea4e0c4f1b96f443614669 not found on branch master. Assuming force push.
...
2024-05-21 15:30:18,472 INFO [15-BAM::SpecsDetection:pool-20-thread-4] [AllTypesSpecsImporter] Bamboo Specs import took 799.5 ms
(no messages about change detection in the repo, no build dispatched)

As pointed out in the Bamboo variables documentation, it's key to remember that Bamboo variables get evaluated on the fly at the time the build is supposed to run. Here's the gist:

... variables are evaluated by Bamboo dynamically at build time.

This means if the Specs feature tries to swap out the master-branch value with "${bamboo.oculus_defaultBranch}" and the specified branch doesn't exist in the remote repository, Bamboo ends up using an empty string for the repository configuration. This is what leads to the issue at hand.

Workaround

This can be fixed by ditching the variable in the YAML file and directly setting master-branch: master, without variable.

The goal is to at least get an error message out to the user, explaining why the build didn't proceed, if tweaking the underlying logic isn't on the table.