So is this about having a cli option to the changelog command to be able to push the changelog to gitlab as well?

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.:

git remote -v
origin  git@github.com:user/package-xyz.git (fetch)
origin  git@github.com:user/package-xyz.git (push)
origin-internal      git@gitlab.example.com:user/package-xyz.git (fetch)
origin-internal      git@gitlab.example.com:user/package-xyz.git (push)

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.

That sounds like a good idea.

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?

No update yet, still in the back log

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?

No change, still in backlog

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?

My new thought on this is that you can gain what you are looking for with two release configurations. One for GitLab and one for GitHub and then use the -c option to select the one you desire for that run. If you have one in the pyproject.toml file this will be selected by default in the one job and then your other one could be github-releaserc.toml. Unfortunately you will have to keep all the other settings in sync manually since we don't have a cli switch to toggle which repository but this would get you some level of capability.

I'm not sure if we will ever add the cli option to set the remote url directly but might make it handle multiple remotes configurations instead (with some toggle mechanism in between).

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?

Still in backlog