Avoid the need to have git phr as a configured alias #337
Conversation
| @@ -51,7 +51,9 @@ fi | |||
| git commit -m "Release $FULLVERSION" | |||
|
|
|||
| if [[ $PACKAGING_PR == true ]] ; then | |||
| git phr -m "Release $FULLVERSION" -b "$REMOTE_BRANCH" | |||
| # TODO: assumes a remote named whoami for the user's fork | |||
There was a problem hiding this comment.
If you really want to script this and reduce the amount of assumptions and manual set-up required, our team has been using this ansible role for well over a year to deploy all of the source and tooling repositories used for building hotfix RPMs: theforeman/forklift#1580
I've been using it to manage all of the repositories in my katello devel box for a similar length of time as well.
There was a problem hiding this comment.
I'm not a fan of using VMs for those common tasks. It's always awkward when I miss my own customization.
| git push --set-upstream "$(whoami)" HEAD | ||
| hub pull-request -m "Release $FULLVERSION" -b "$REMOTE_BRANCH" |
There was a problem hiding this comment.
I've been using gh and there it's gh pr create and it will take care of pushing and everything.
There was a problem hiding this comment.
Somehow I thought gh was written in Javascript and always ignored it, but now I see it's not and it's even packaged in Fedora. Maybe I'll take some time to look at converting.
There was a problem hiding this comment.
Yeah, I'm using the Fedora package and it's quite OK for the things I needed it for.
There was a problem hiding this comment.
I noticed you often push to the original repository instead of your own fork, which is something I'd like to avoid. Is that because of gh behavior?
There was a problem hiding this comment.
No, that's my lazyness, you can tell it where to push to. I just often don't even have an own fork (configured)
I'm not 100% sure this is better or worse, but it needs some solution. Either we document the aliases or finish this.
Came up in #336