fix: introduce dedicated option for GitHub API endpoint

[fgreinacher]

Server and API endpoints can be different. Some code parts, e.g. issue parsing, need the server endpoint and we should make this explicit. The existing githubApiPathPrefix option is not sufficient when the API is served from a different host (like api.github.com).

Fixes #827

⚒️ with ❤️ by Siemens

[fgreinacher]

Independent of this change it might also be worth to deprecate some of these variables to align with what is currently supported: https://docs.github.com/en/actions/learn-github-actions/variables.

[travi]

thanks for reporting and investigating. i hadnt noticed this behavior, but see it in other releases now that i'm looking for it. i'm unsure when it began or what it might be related to.

i havent investigated very far yet, but it seems odd to me to need to adjust for this. since octokit is used for the interactions with github, most of the differences between using github.com and a self-hosted github enterprise server instance should be covered by the existing config options. this feels more like a regression or octokit api mismatch somewhere to me, but would need to investigate further to understand better.

i'm curious if @gr2m is aware of anything obvious that might be contributing to this situation

[gr2m]

I'll try to have a look this week

[fgreinacher]

thanks for reporting and investigating. i hadnt noticed this behavior, but see it in other releases now that i'm looking for it. i'm unsure when it began or what it might be related to.

i havent investigated very far yet, but it seems odd to me to need to adjust for this. since octokit is used for the interactions with github, most of the differences between using github.com and a self-hosted github enterprise server instance should be covered by the existing config options. this feels more like a regression or octokit api mismatch somewhere to me, but would need to investigate further to understand better.

i'm curious if @gr2m is aware of anything obvious that might be contributing to this situation

I'm quite sure it's not an Octokit (configuration) issue. The regular API requests via Octokit are working fine. The problem occurs when the plugin code is filtering detected issue references:

1. the plugin code is configuring the underlying issue-parser library with hosts = [gitHubUrl]: https://github.com/semantic-release/github/blob/master/lib/success.js#L56.
2. gitHubUrl contains the GitHub API URL (api.github.com)
3. the issue-parser library uses that URL to derive the slug: https://github.com/semantic-release/issue-parser/blob/master/index.js#L52.
4. that slug is wrong when the input text contains full URLs as issue references (e.g. https://github.com/semantic-release/github/issues/827)
5. the GitHub plugin uses the slug to find relevant issue references: https://github.com/semantic-release/github/blob/master/lib/success.js#L116
6. with the wrong slug it will filter out full URL issue references and not comment on any of them

---

TLDR: issue-parser needs the root GitHub URL, octokit needs the GitHub API URL, and we do not disambiguate these currently.

---

I guess this broke in #269, with it's 4th birthday tomorrow :)

[gr2m]

Outstanding pull request, thank you @fgreinacher 💐 Changes and reasoning all look good to me, and code + tests are great 👍🏼

[github-actions]

🎉 This PR is included in version 10.0.4 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀