Feature request: deploying to `main` branch on production

gabebw commented 4 years ago

As of July 21, 2020, Heroku supports deploying to the main branch: https://devcenter.heroku.com/changelog-items/1829

They also encourage customers to switch to main from master.

What command did you execute?

production deploy, on the main branch

What did you expect to happen?

Parity should run git push production main

What actually happened?

Parity couldn't find the nonexistent master branch and crashed.

$ git branch
* main
$ production deploy
error: src refspec master does not match any
error: failed to push some refs to 'https://git.heroku.com/hotline-webring-production.git'
zsh: exit 1     production deploy

Some information about your installation

What's your operating system? macOS
What's the output of which development, which staging, which production? Parity has had multiple installation channels, and it's not uncommon for an old version to be somewhere else in your path.
- All are in /usr/local/bin/COMMAND

If installed via Homebrew, what does brew list parity output?

$ brew list parity
/usr/local/Cellar/parity/3.3.0/bin/development
/usr/local/Cellar/parity/3.3.0/bin/pr_app
/usr/local/Cellar/parity/3.3.0/bin/production
/usr/local/Cellar/parity/3.3.0/bin/staging
/usr/local/Cellar/parity/3.3.0/lib/parity/ (5 files)
/usr/local/Cellar/parity/3.3.0/lib/parity.rb

If installed via Rubygems, what's the gem version?

N/A

geoffharcourt commented 4 years ago

Hi @gabebw!

I'm trying to figure out how to handle staging scenarios. In staging, we push the current branch to the staging primary branch, but now I'm not sure what the reliable way to determine what the name of the remote main branch would be.

In https://github.com/thoughtbot/dotfiles we're using this technique, but I'm not sure if it that would work. I'll do some investigation.

gabebw commented 4 years ago

Hi @geoffharcourt!

Yes, this would apply to both staging (current -> main/master) and production (main/master -> main/master).

Interestingly, git symbolic-ref --short refs/remotes/origin/HEAD gives me origin/master locally in a repo that used to use master but switched to main, so something's funky there. I think that Parity's technique is allowed to be a little more expensive and a little less fancy than that dotfiles technique, since Parity will run deploys so much less frequently.

Thus, another idea is to check if there's (1) a local main branch and (2) no master branch, and in that case use main. I like that because it would solves the 80%+ case, and would be my preference.

Or: what about a manual Git configuration setting? That way it can be per-repo (with .git/config, and set in bin/setup) or system-wide (with ~/.gitconfig). Something like this:

git config --global parity.primaryBranchName main

I'd expect it to default to master if that setting doesn't exist.

I like that it's naturally scoped to the system or repo because of the way git reads gitconfigs. For example, I've switched to main everywhere, so I'd set it to main in ~/.gitconfig and override that to master on a per-repo basis.

mrjonesbot commented 3 years ago

@geoffharcourt @gabebw Took a stab at a more intuitive deploy command: https://github.com/thoughtbot/parity/pull/188

The change checks for the presence of main and the absence of master -- setting the branch ref appropriately.

Avoids manual / global git configs and doesn't break projects where master is still the default branch.

thoughtbot / parity