Repository navigation
feat: publish to two different remote VCS #149
Description
Activity
So is this about having a cli option to the changelog command to be able to push the changelog to gitlab as well?
Reacted by Alexander DunkelYes, either this, or a cli option to select the remote by name (and if it is a gitlab-remote, it will update/release the changelog using the GL_TOKEN; if it is a github-remote, it will update/release the changelog using the GH_TOKEN).
Does this make sense?
To add some information: we usually have two remotes, one for internal collaboration where we push additional branches etc., and a github-remote, where only the master branch is published. E.g.:
git remote -v origin [email protected]:user/package-xyz.git (fetch) origin [email protected]:user/package-xyz.git (push) origin-internal [email protected]:user/package-xyz.git (fetch) origin-internal [email protected]:user/package-xyz.git (push)
I'd like to publish the changelog/releases to both
originandorigin-internal, currently, it is only posted to the default remote (origin) when usingsemantic-release publish.That sounds like a good idea.
Reacted by Alexander DunkelTo add to this, I'd like the ability to identify a second branch to push to. I use a dual branch (dev/master) release system and that sounds like it could just built in to this feature request. There's added complexity allowing for multiple remotes over multiple branches but it seems like a natural extension.
Let me know if you think multiple branch pushes should just be it's own request.
11 remaining items
- changed the title
[-]Any way to set remote repository in cli mode?[/-][+]feat: publish to two different remote publishing[/+]on Oct 3, 2024 - changed the title
[-]feat: publish to two different remote publishing[/-][+]feat: publish to two different remote VCS[/+]on Oct 3, 2024 It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
One way to accomplish this would also be to add a --remote-type command line option, then you could pass "gitlab" or "github", overriding the configuration file's remote.type.
Reacted by Alexander DunkelI would prefer a #1099 implementation so that I'm not maintaining adding a new cli option for every variance that comes up over the future of the project. We already have a lot.
Have we considered what other options have to change once the new remote type changes? Is the remote URL gathered from the environment? Is the access token have the same name etc?
It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
Still in backlog
Reacted by Alexander DunkelIt has been 90 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
My situation may appear a little bit untypically, but perhaps this is already implemented:
So far, I've only released
releasesin Github, because it was not possible in python-semantic-release to setup custom Gitlab instances.Since
GL_TOKENbecame available, I'd also like to publish releases to themasterbranch on our custom Gitlab instance.However, python-semantic-release seems to only use the remote that is set as default git remote. Is there any way to have it simultaneously publish releases to both Github and Gitlab using GH_TOKEN (e.g. remote
origin) and GL_TOKEN (e.g. remotegl_origin)?Alternatively, manually publishing/updating all releases to Gitlab would be totally ok for me, if there was such an option..