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
My situation may appear a little bit untypically, but perhaps this is already implemented:
we have a closed Gitlab instance that we use for internal software development
we publish some of our branches/tools to Github, for external code collaboration
So far, I've only released releases in Github, because it was not possible in python-semantic-release to setup custom Gitlab instances.
Since GL_TOKEN became available, I'd also like to publish releases to the master branch 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. remote gl_origin)?
Alternatively, manually publishing/updating all releases to Gitlab would be totally ok for me, if there was such an option..
Yes, 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.:
I'd like to publish the changelog/releases to both origin and origin-internal, currently, it is only posted to the default remote (origin) when using semantic-release publish.
To 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.
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.
I 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?
It 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?
Activity
relekang commentedon Sep 19, 2019
So is this about having a cli option to the changelog command to be able to push the changelog to gitlab as well?
Sieboldianus commentedon Sep 20, 2019
Yes, 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.:
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.relekang commentedon Sep 20, 2019
That sounds like a good idea.
alandtse commentedon Mar 31, 2020
To 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
[-]Any way to set remote repository in cli mode?[/-][+]feat: publish to two different remote publishing[/+][-]feat: publish to two different remote publishing[/-][+]feat: publish to two different remote VCS[/+]github-actions commentedon Feb 1, 2025
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?
thedannymarsh commentedon Mar 19, 2025
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.
codejedi365 commentedon Mar 20, 2025
I 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?
github-actions commentedon May 19, 2025
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?
codejedi365 commentedon May 20, 2025
Still in backlog
github-actions commentedon Aug 18, 2025
It 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?