Support configuring the GitHub server URL

[megamorf]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

We started the upgrade from v5 to v6 today - specifically ghcr.io/super-linter/super-linter:slim-v6.4.1. However in our GHES environment the super-linter run fails with the error below.

Expected Behavior

The built-in github context variables should be supported by the action: https://docs.github.com/en/[email protected]/actions/learn-github-actions/contexts#github-context

The documentation says:

github.server_url	string	The URL of the GitHub server. For example: https://github.com.

It does not make sense as a big corporate customer to reinvent the wheel. In the URL building logic of the Action a condition needs to be added to strip an extra schema from the input so that the github.server_url variable can be handled correctly.

Super-Linter version

v6.4.1

Relevant log output

Super-Linter initialization
2024-04-25 15:43:00 [INFO]   Command output when running linters:
------
BASH
GITHUB_ACTIONS
GITLEAKS
JSON
MARKDOWN
YAML
------
2024-04-25 15:43:00 [INFO]   ----------------------------------------------
2024-04-25 15:43:00 [INFO]   ----------------------------------------------
Notice: 25 15:43:00 [NOTICE]   Successfully linted BASH
2024-04-25 15:43:00 [INFO]   Failed to call GitHub Status API: curl: (6) Could not resolve host: api.https
Notice: 25 15:43:00 [NOTICE]   Successfully linted GITHUB_ACTIONS
2024-04-25 15:43:00 [INFO]   Failed to call GitHub Status API: curl: (6) Could not resolve host: api.https
Error: -25 15:43:00 [ERROR]   Errors found in GITLEAKS
2024-04-25 15:43:00 [INFO]   Failed to call GitHub Status API: curl: (6) Could not resolve host: api.https
Notice: 25 15:43:00 [NOTICE]   Successfully linted JSON
2024-04-25 15:43:00 [INFO]   Failed to call GitHub Status API: curl: (6) Could not resolve host: api.https
Notice: 25 15:43:00 [NOTICE]   Successfully linted MARKDOWN
2024-04-25 15:43:00 [INFO]   Failed to call GitHub Status API: curl: (6) Could not resolve host: api.https
Notice: 25 15:43:01 [NOTICE]   Successfully linted YAML
2024-04-25 15:43:01 [INFO]   Failed to call GitHub Status API: curl: (6) Could not resolve host: api.https
Error: -25 15:43:01 [ERROR]   Super-linter detected linting errors

I ran the workflow in debug mode to see what exactly is going on and it seems that you are incorrectly building the URL paths:

  [...]
  2024-04-25 15:55:59 [INFO]   Successfully found GITHUB_SHA: 36f8c32e4a1fffa7047eeb7965e8ab77d5d42493
  2024-04-25 15:55:59 [DEBUG]   Successfully found the root commit: 27261c4ca041a0bccdedf1987d212cfe107dcb35
  2024-04-25 15:55:59 [DEBUG]   This is a GitHub pull request. Updating the current GITHUB_SHA   (36f8c32e4a1fffa7047eeb7965e8ab77d5d42493) to the pull request HEAD SHA
  2024-04-25 15:55:59 [DEBUG]   Updated GITHUB_SHA: 83815cb76f3bf28e4ce229d1e116b5299352e335
  2024-04-25 15:55:59 [INFO]   Successfully found GITHUB_ORG: my-cool-org
  2024-04-25 15:55:59 [INFO]   Successfully found GITHUB_REPO: star-chaser-config
  2024-04-25 15:55:59 [DEBUG]   Successfully detected the default branch for this repository: master-caas-v3
  2024-04-25 15:55:59 [INFO]   The default branch for this repository is set to: master-caas-v3
  2024-04-25 15:55:59 [INFO]   Successfully found GITHUB_TOKEN.
  2024-04-25 15:55:59 [INFO]   Successfully found GITHUB_REPOSITORY: my-cool-org/star-chaser-config
  2024-04-25 15:55:59 [INFO]   Successfully found GITHUB_RUN_ID 6446359
- 2024-04-25 15:55:59 [DEBUG]   GitHub Status URL: https://api.https://git.contoso.com/repos/my-cool-org/star-chaser-config/statuses/83815cb76f3bf28e4ce229d1e116b5299352e335
- 2024-04-25 15:55:59 [DEBUG]   GitHub Status target URL: https://https://git.contoso.com/my-cool-org/star-chaser-config/actions/runs/6446359
  2024-04-25 15:55:59 [DEBUG]   Configuring Git safe directories
  2024-04-25 15:55:59 [DEBUG]   Set /github/workspace as a Git safe directory
  2024-04-25 15:55:59 [DEBUG]   Set /tmp/lint as a Git safe directory
  2024-04-25 15:55:59 [DEBUG]   Set /tmp/lint as a Git safe directory
  2024-04-25 15:55:59 [DEBUG]   TYPESCRIPT_STANDARD_TSCONFIG_FILE: /github/workspace/tsconfig.json
  2024-04-25 15:55:59 [DEBUG]   R_RULES_FILE_PATH_IN_ROOT: /github/workspace/.lintr
  2024-04-25 15:55:59 [INFO]   --------------------------------------------
  2024-04-25 15:55:59 [INFO]   Validating the configuration
  2024-04-25 15:55:59 [DEBUG]   Set VALIDATE_LANGUAGE while validating the configuration: VALIDATE_ANSIBLE
  2024-04-25 15:55:59 [DEBUG]   Configuration didn't provide a custom value for VALIDATE_ANSIBLE
  2024-04-25 15:55:59 [DEBUG]   Set VALIDATE_LANGUAGE while validating the configuration: VALIDATE_BASH
  [...]

Steps To Reproduce

The Action itself is called as follows and has been working fine with v5 - switching to v6.4.1 fails with the linked error.

# [...]

jobs:
  lint:
    runs-on: [contoso-x86-2core]
    steps:
      - name: Checkout Code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Super-Linter
        uses: github/super-linter/slim@v6
        env:
          GITHUB_DOMAIN: ${{ github.server_url }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          VALIDATE_MARKDOWN: true
          VALIDATE_YAML: true
          VALIDATE_BASH: true
          VALIDATE_GITLEAKS: true
          VALIDATE_GITHUB_ACTIONS: true
          VALIDATE_DOCKERFILE_HADOLINT: true
          LINTER_RULES_PATH: /
          YAML_CONFIG_FILE: .yamllint.yaml

# [...]

Anything else?

No response

[megamorf]

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

[ferrarimarco]

@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.

[ferrarimarco]

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.

[megamorf]

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

[megamorf]

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.