Skip to content

commands are failing for self hosted gitea release hosted via http #1169

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ste1nstone opened this issue Feb 3, 2025 · 5 comments · Fixed by #1173
Closed

commands are failing for self hosted gitea release hosted via http #1169

ste1nstone opened this issue Feb 3, 2025 · 5 comments · Fixed by #1173
Labels
bug Something isn't working properly confirmed Prevent from becoming stale released

Comments

@ste1nstone
Copy link

Bug Report

Description

Hi I think I encountered the same problem like described in the bug #1074 today.
I tried to run semantic release on an action with my self hosted gitea instance that is hosted via http.

Image

Here is my remote config

[semantic_release.remote]
name = "origin"
domain = "http://gitea:3000"
type = "gitea"
insecure = true

what I noticed during my investigations was that gitea sets the same env variables like github. So the following environment variables are set in the pipeline:

  • GITHUB_SERVER_URL
  • GITHUB_API_URL

For testing I tried to unset the two env vars before executing semantic release it worked.

unset GITHUB_SERVER_URL
unset GITHUB_API_URL

I assumtion is that semantic release somehow does a remote auto config based on the env variables.
But I do not understand the code enough to validate that theory.

It can also be reproduced without a cicd pipeline
Just set the GITHUB_SERVER_URL env variable with a http schema and run semantic-release --version

$env:GITHUB_SERVER_URL = "http://gitea:3000"
semantic-release --version

This already leads to the same issue on my local windows pc

Hope this info helps someone with fixing the issue.

BR
Philipp

@ste1nstone ste1nstone added bug Something isn't working properly triage waiting for initial maintainer review labels Feb 3, 2025
@codejedi365
Copy link
Contributor

@ste1nstone, thanks for the report. I think I understand what is happening now as the previous issue the author never responded. It's loading the default config object before reading your configuration and then reads your configuration but it throws an error before it reads your configuration. Not quite what was expected.

codejedi365 added a commit to codejedi365/python-semantic-release that referenced this issue Feb 7, 2025
… insecure URL error

Due to the previous default token loading, PSR configuration load would
initate the default RemoteConfig. During validation of the remote config,
the HVCS object was initialized and upon initialization the URL is evaluated
for insecure protocol causing errors when the URL was pulled from the env.

This change removes the need for initialization which means the URL validation
will not occur pre-maturely

Resolves: python-semantic-release#1169, python-semantic-release#1074
@codejedi365
Copy link
Contributor

@ste1nstone, would you test out the following pre-release to see if it resolves the issue in your environment?

https://github.com/codejedi365/python-semantic-release/releases/tag/v9.18.1-alpha.1

@codejedi365 codejedi365 added confirmed Prevent from becoming stale awaiting-reply Waiting for response and removed triage waiting for initial maintainer review labels Feb 7, 2025
@ste1nstone
Copy link
Author

@codejedi365 with the new version it now also works without having to unset the two variables first.
Thanks for the fix and the cool project

@codejedi365
Copy link
Contributor

@ste1nstone, you're welcome!

@codejedi365 codejedi365 removed the awaiting-reply Waiting for response label Feb 8, 2025
@codejedi365
Copy link
Contributor

🎉 This issue has been resolved in Version 9.18.1 🎉

You can find more information about this release on the GitHub Releases page.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working properly confirmed Prevent from becoming stale released
Projects
None yet
2 participants