Support configuring the GitHub server URL about super-linter HOT 5 OPEN

@ferrarimarco introduced this regression with this change:
6fd6830#diff-0b89e6e14353371aacf69d4b9067d4481dd99c6994409b32e3b906c69d478c21L147-L149 (working code left, regression right).

from super-linter.

@megamorf You are setting GITHUB_DOMAIN, which is for the domain of your installation, not for the server URL, as you can see from the README.

The commit you reference fixed a few inconsistencies about variables not behaving as described in the documentation, and it also disallowed some confusing corner cases that allowed you to set GITHUB_DOMAIN and GITHUB_CUSTOM_API_URL in a completely independent way, which is likely error prone.

The current implementation works if you set GITHUB_DOMAIN to your domain and not to github.server_url.

This is an enhancement request, rather than a bug because support for github.server_url was never implemented in the first place.

Happy to review a PR for this.

from super-linter.

At least you can set GITHUB_API_URL: ${{ github.api_url }} which should make the API call work, but the resulting status check would have the wrong target URL because GITHUB_DOMAIN points to the wrong link. This, provided that the GitHub API doesn't reject invalid target links for status checks. Given that we can set GITHUB_API_URL in the current implementation, it probably makes sense to have something comparable for the GitHub server URL.

I think we likely need to:

• Expose the GITHUB_SERVER_URL variable because we cannot use GITHUB_DOMAIN for this. GITHUB_DOMAIN is a convenience variable to automatically build the URL of the GitHub instance and the URL of its API server. Maybe we should make this clearer in the README.
• Validate all these variables to handle corner cases, such as when the user sets GITHUB_DOMAIN and any of GITHUB_SERVER_URL and GITHUB_API_URL, or both.

from super-linter.

As it is now, it would require a GHES instance with +20.000 users to needlessly introduce a workaround across all workflows (stripping the schema from github.server_url) just to adhere to what appears to be arbitrarily chosen input requirements.

server_url is part of the github context for both github.com and GHES. So I'd very much be in favour of introducing support for those built-in variables.

Also, for transparency, in our case the following two context variables are not pointing to different domains:

github.server_url: https://git.foo.contoso.com
github.api_url:    https://git.foo.contoso.com/api/v3

from super-linter.

I think we likely need to:

• Expose the GITHUB_SERVER_URL variable because we cannot use GITHUB_DOMAIN for this. GITHUB_DOMAIN is a convenience variable to automatically build the URL of the GitHub instance and the URL of its API server. Maybe we should make this clearer in the README.
• Validate all these variables to handle corner cases, such as when the user sets GITHUB_DOMAIN and any of GITHUB_SERVER_URL and GITHUB_API_URL, or both.

Yeah, that sounds like the most reasonable approach. I guess we first need to compile the different allowed/forbidden states and then refactor the logic accordingly. Let me know how I can help here to remove the blocker.

Edit: Can we put in the step for the GITHUB_SERVER_URL that removes and re-adds the schema as a temporary workaround until we're clear on how the new input handling looks like? That way affected users like us can profit from fancy new v6 features while work is ongoing on improving the implementation and documentation.

from super-linter.