config remote name is not respected

[matthiasgleichauf]

The problem

The documentation says I can configure the push target via

[tool.semantic_release.remote]
name='origin'

https://python-semantic-release.readthedocs.io/en/latest/configuration.html#tool-semantic-release-remote

yet the code does always asks the hvcs_client for its URL, ignoring the setting, see version.py#L530-L532

Expected behavior

I would expect the version command to respect setting the name of the remote and pushing there instead of constructing the URL directly from the hvcs client.

Environment

Please state which OS you are using and provide the output of the following commands:

python --version
Python 3.11.7

pip --version
pip 23.3.2 from /usr/local/lib/python3.11/site-packages/pip (python 3.11)

semantic-release --version
semantic-release, version 8.7.0

pip freeze
annotated-types==0.6.0
certifi==2023.11.17
charset-normalizer==3.3.2
click==8.1.7
dotty-dict==1.3.1
gitdb==4.0.11
GitPython==3.1.41
idna==3.6
importlib-resources==6.1.1
Jinja2==3.1.3
markdown-it-py==3.0.0
MarkupSafe==2.1.3
mdurl==0.1.2
pydantic==2.5.3
pydantic_core==2.14.6
Pygments==2.17.2
python-gitlab==4.4.0
python-semantic-release==8.7.0
requests==2.31.0
requests-toolbelt==1.0.0
rich==13.7.0
shellingham==1.5.4
smmap==5.0.1
tomlkit==0.12.3
typing_extensions==4.9.0
urllib3==2.1.0

Please also indicate which Python build tool(s) you are using (e.g. pip, build,
poetry, etc.), including the version number too.
pip

Configuration

Please add your semantic-release configuration, and if applicable also provide
your build-system configuration from pyproject.toml.
build command is:
pip wheel . -w dist --no-deps --prefer-binary

pyproject.toml:

`[tool.semantic_release]
build_command = 'pip wheel . -w dist --no-deps --prefer-binary'
version_variables = ["src/__version__.py:version"]

[tool.semantic_release.branches.main]
match = "master"
prerelease = false

[tool.semantic_release.branches.develop]
match = "develop"
prerelease = true
prerelease_token = "dev"

[tool.semantic_release.remote]
name = "origin"
domain = '[REDACTED_GIT_URL_HOST]'
ignore_token_for_push = true

[tool.semantic_release.publish]
upload_to_vcs_release = false
`

Logs

Attached in semantic.log created by running

git config --global --add safe.directory $PWD
semantic-release -vv version --no-changelog --no-vcs-release --patch > semantic.log 2>&1

Additional context

This is run in a docker container started like this:
docker run -t -i -u root --entrypoint=bash -w [REDACTED_PATH] -v [REDACTED_PATH]:[REDACTED_PATH]:rw,z python:3.11

[codejedi365]

The reason that the code asks the hvcs, is because previously during the configuration load step the hvcs was configured with the url from origin. Essentially they are the same thing. I would be curious if your token actually has permissions to write the repository. I assume you are using a GitHub on premise or SaaS where you have a custom domain? Are you running it locally or through the CI? If it is the CI make sure the github token value was granted the proper permissions which are contents: write and id-token: write.

[matthiasgleichauf]

Thanks for your reply, I should've justified that failure: I let it intentionally fail on auth, since I didn't want all the debugging tags pushed to the origin repo, while understanding the issue.
I'm using some custom git flavor on premise with a custom domain, so the type doesn't really matter, hence I didn't set it (I tried setting gitlab as well though). I would like semantic release to just do a git push origin master. Reasoning is that I wouldn't have to configure the custom domain in my pyproject.toml, which would make it easier to transport etc. The CI in which this is run, checks out the repo and configures the git remote.
If I don't specify the custom domain, semantic-release guesses github.com, which is understandable, but for my case wrong ;)

[codejedi365]

@matthiasgleichauf, Well the type of the VCS is actually required for python-semantic-release currently. We make it optional for the user but assume GitHub when not provided. The client code sets up the domains if not provided which is how you are getting github.com.

I have a solution in work to solve #734 (no VCS), which I think will be your desired use but its not ready yet.

If I understand your desired configuration, your best bet is to run the push manually as a separate step and let semantic do the upfront work.

semantic-release version --no-push --no-changelog --no-vcs-release
git push origin master --tags

I'll revisit this when I finish #734, and see if there is some issue that the current code is not considering as the current implementation does seem a bit odd to have this side-effect.