Prompt when local ref does not match remote ref

[sanjayprabhu]

Say you're on master locally, if you deploy -e production it's possible that it's going to deploy an older version because someone has pushed remote master after you last pulled. You need to always git pull if you're not providing the ref, to make sure that you're deploying the correct version.

[ejholmes]

Hmm, this actually shouldn't be a problem, right? If you're on master, then it's going to create the deployment using the master ref and get resolved on GitHub, which will resolve it to the current HEAD on GitHub.

But it's still a good point, it's not really clear what sha is actually being deployed when the ref is resolved using git.

[sanjayprabhu]

Does it use the master ref? It deployed the local SHA to staging for me (to staging). Let me see if I can reproduce it.

[ejholmes]

Yeah, it'll use the master ref if you're using v0.0.2.

[sanjayprabhu]

Ah, I was on v0.0.1.

But yeah, would be nice to see the sha and provide a warning if it doesn't match the local sha.

[ejholmes]

Yeah, that would be nice. It's pretty easy right now to push a commit, then deploy before the new HEAD actually registers on github.

Could probably use the GET /repos/:owner/:repo/git/refs/:ref endpoint to resolve the branch to a sha and check that it matches HEAD

[sanjayprabhu]

I'll give it a shot when I have some time.

[bmarini]

This is still an issue actually. If I have repo1@develop checked out locally and run deploy -e production repo2 it'll attempt to deploy repo2@develop which is not what i expect (i'd expect it to default to master).

[ejholmes]

Ah yeah, that's definitely a legit bug. If you specify a repo on the command line, we shouldn't fallback to git.