Should an exception be thrown for duplicate redis keys?

[ember-cli-deploy]

Should an exception be thrown for duplicate redis keys?

[achambers]

Closing based on the last comment in this thread

[ghedamat]

hi @mariogintili

thanks for this.

Could you remove the Gemfile.lock commit from this PR?

I see it's doing a major update for jekill and I'd rather have that separate (and checked) as there might be some breaking stuff in there

thanks!

[shellandbull]

hello @ghedamat there isn't a Gemfile.lock in any commit because this isn't a PR, is an issue 😄

[ghedamat]

oh gosh, sorry @mariogintili I meant to answer another PR :p, too many tabs open :D

we had a discussion with @achambers about your issue, I believe he'll post the results here soon :)

[achambers]

@mariogintili After some discussion with the team about this it was decided that, for CI, the default value of allowOverwrite should really be true which would mean you would never find yourself in the situation.

The allowOverwrite config option is really a hangover from 0.4.x where the default revision key strategy was using the git sha, and developers testing deploys from their development environment didn't want to have to commit each time they made a change to test their deploy.

The flag can still be used for this but it is the team's view that a CI environment can be viewed as a controlled environment where you can be reasonably confident that you know the state of your code at a point in time and therefore can set allowOverwrite == true.

It seems that maybe the real change to be made is to the documentation around allowOverwrite, how it came to be, what it is intended for and how it should be used.

Maybe we can use this issue to track that change instead?