You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is it possible to configure which remote reckonTagPush pushes tags to?
Context:
At my workplace, all developers create their own fork of the main repository for a given project and submit pull requests back to the main repository (remote upstream) from their fork (remote origin).
reckonTagPush pushes tags to origin, which means that developers responsible for releasing versions via tags would have to have a second checkout with origin pointing to the main repository rather than just doing the equivalent of git push upstream <tagname>.
The text was updated successfully, but these errors were encountered:
Currently, this isn't configurable. It pushes to whatever remote your current branch is tracking. This could probably enhanced, though I'd probably be looking for someone to contribute this one, since it won't be high on my list.
As a workaround, you can run reckonTagCreate then do the git push upstream <tagname>.
Having a configurable remote is not only useful for forks. Bamboo clones repos into a cache copy, then when your project builds, it gets cloned from Bamboo's cache copy instead of the remote server. As a result, if you push your release to origin, it only pushes to Bamboo's cache clone and never makes it to the remote server. The only way around this is to add a new remote and push the release to that remote. So, being unable to configure the remote to push to makes it impossible to use this plugin with Bamboo, if I am correctly understanding the limitations of reckon.
Is it possible to configure which remote
reckonTagPush
pushes tags to?Context:
At my workplace, all developers create their own fork of the main repository for a given project and submit pull requests back to the main repository (remote
upstream
) from their fork (remoteorigin
).reckonTagPush
pushes tags toorigin
, which means that developers responsible for releasing versions via tags would have to have a second checkout withorigin
pointing to the main repository rather than just doing the equivalent ofgit push upstream <tagname>
.The text was updated successfully, but these errors were encountered: