Allow BUILD_ID to be set using generateBuildId (minor)

[craigmcnamara]

Fixes #786

This makes multi server deploys with Capistrano possible.

I couldn't see a place to add tests for a thing like this, but I'm happy to if you point the way.

[arunoda]

@craigmcnamara thanks for this.
I see the validity of this.

I think it's better to get this via next.config.js. Could you modify your PR?

[craigmcnamara]

I'm happy to rework this. Thanks for the feedback.

[timneutkens]

Lets do it like this:

let buildId
if(typeof config.generateBuildId === 'function') {
  buildId = await config.generateBuildId() // `await` so that it can be an async function
} else {
  buildId = uuid.v4()
}

This will allow the user to generate the buildId in whatever way they like, because you can do something async to get the buildId, like reading from the filesystem or fetching from some api.

[timneutkens]

Lets also add an integration test for this case.

[bessey]

(I work with @craigmcnamara) I have updated the PR as suggested. I couldn't find a comparable test that asserts config behaviour, so was unable to write a test that asserts this works. All I know is it doesn't crash, which isn't really enough, I admit.

That said, now that I'm more familiar with this code, it seems odd to me that the default implementation is not stable. Is it unreasonable to default to generating an ID by hashing the contents of the project directory? There seem to be some quite small existing libraries that tackle this concern.

[lukasz-karolewski]

it would be very much desired to get build_id based on contents of source (everything in current directory) this will make docker builds more predictable, this becomes an issue when used with CDN

[raffij]

We’d like to see this completed and merged to for deployment purposes. Rather than relying on sticky sessions.

Our first thought was using build_id from the git hash.

[timneutkens]

Made some improvements, going to merge when the tests pass.