Removes URLs from environment variables

[simonbs]

This PR removes NEXTAUTH_URL_INTERNAL, previously needed to workaround a bug in the Auth.js 5.0 beta, which is no longer necessary.

It also removes FRAMNA_DOCS_BASE_URL, used for constructing preview links in PR comments. We now dynamically extract the host from the URL that triggered the webhook, eliminating hardcoded URLs.

This removes all hard-coded URLs, making it simpler to deploy Shape Docs and access it from different domains.

[github-actions]

⚠️ It looks like .env.example has changed. Remember to update the Setting Environment Variables article accordingly.

[ulrikandersen]

It also removes FRAMNA_DOCS_BASE_URL, used for constructing preview links in PR comments. We now dynamically extract the host from the URL that triggered the webhook, eliminating hardcoded URLs.

That's really nice 🙌

One small concern for me is that since we have only a single instance of GitHubHookHandler the hostURL is persisted across requests and will change if/when a webhook request has a different source host. You have probably already considered this, and we will probably be just fine with this behaviour. Just wanted to raise it.

[simonbs]

One small concern for me is that since we have only a single instance of GitHubHookHandler the hostURL is persisted across requests and will change if/when a webhook request has a different source host.

“I considered this, but I’m struggling to determine if it’s actually an issue.

The webhook URL is configured in the GitHub app and is always a single URL. Therefore, the host we store will be consistent. However, even if the URL host changes between invocations, wouldn’t we want to capture that change? This way, we store the host for each invocation and use it a few milliseconds later.

There could be a race condition here, but I’m not sure how likely it is to occur in practice or what the best solution would be.

[ulrikandersen]

The webhook URL is configured in the GitHub app and is always a single URL. Therefore, the host we store will be consistent. However, even if the URL host changes between invocations, wouldn’t we want to capture that change? This way, we store the host for each invocation and use it a few milliseconds later.

There could be a race condition here, but I’m not sure how likely it is to occur in practice or what the best solution would be.

Sounds like you've already considered this case. Thanks for the answer 🙏

I am comfortable with merging this. I don't think the modification of the hostURL will become a problem in practise.