trigger function errors when .yml is named incorrectly

[kellyoung]

Today, we got an alarm because the trigger function error'ed when an incorrectly named .yml file was used.

2017-11-02T18:36:28.441Z    bc7ecdd9-bffc-11e7-aba8-f192b47c1978
{
    "errorMessage": "ENOENT: no such file or directory, open '/var/task/buildspecs/node4.3.yml'",
    "errorType": "Error",
    "stackTrace": [
        "Error (native)",
        "Object.fs.openSync (fs.js:641:18)",
        "Object.fs.readFileSync (fs.js:509:33)",
        "getDefaultBuildspec (/var/task/lambda.js:318:13)",
        "githubToken.then.then.then.then (/var/task/lambda.js:396:33)",
        "process._tickDomainCallback (internal/process/next_tick.js:135:7)"
    ]
}

We should modify the trigger function so that it handles errors such as spelling errors in a different way.

cc/ @mapbox/platform

[rclark]

stork/lambda.js

Line 369 in 529e7f6

return checkRepoOverrides(options);

config object is read from the override files in the repository. This is where config.image ended up node4.3 instead of nodejs4.3.

stork/lambda.js

Line 396 in 529e7f6

options.buildspec = getDefaultBuildspec(config.image);

An attempt to get a default buildspec file for the requested image leads to...

https://github.com/mapbox/stork/blob/master/lambda.js#L318

... and fs.readFileSync on a non-existent file.

---

stork/lambda.js

Line 280 in 529e7f6

if (config.image) result.image = config.image;

Back up here is where the misspelled image is read from the .stork.json file. The catch here is, that we can't just alter the user-provided input, since maybe they want to run on a totally different, public image (not one of stork's defaults).

Instead, I think what we want to catch here is a situation where:

• .stork.json asked for a non-default image
• no buildspec.yml was included in the repository

That's a failure case -- a repository that requests a non-default image must also bring its own buildspec.yml.