Feature request: deploying to `main` branch on production
gabebw opened this issue · 3 comments
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
- All are in
- 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
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.
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.
@geoffharcourt @gabebw Took a stab at a more intuitive deploy command: #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.