[Idea] Support for GitHub Enterprise with EU Data Residency (*.ghe.com)

[arvesolli]

Idea Description

Summary
After attempting to use the AL-Go template within a corporate GitHub Enterprise environment that has data residency in the EU (*.ghe.com), we discovered that the template does not function as expected in this setup.

Details
Through testing and reviewing the AL-Go template code, we identified that repositories hosted on *.ghe.com domains are currently unsupported or incompatible with parts of the template logic (e.g., template updates or remote references relying on github.com).

Request
Please add support for running AL-Go templates on GitHub Enterprise instances with data residency (*.ghe.com domains).
This would enable organizations using Microsoft-hosted GitHub Enterprise environments with regional compliance requirements to fully leverage AL-Go.

Use Case
Many corporate users operate under strict data residency and compliance regulations, which require the use of ghe.com environments. Enabling compatibility would expand AL-Go’s usability to these enterprises.

Environment Example

• GitHub Enterprise URL: https://companyname.ghe.com
• AL-Go template used: https://github.com/microsoft/AL-Go-AppSource

Contribution (Optional)

• I would be open to contributing to this idea (implementation, documentation, testing, etc.)

[aholstrup1]

Just out of curiosity, could you share some more details on what didn't work and what your setup was? I don't believe it's something we've ever tested so this is fairly new territory for us (and AL-Go).

[arvesolli]

example from workflow Update AL-Go System Files:

[main] Update AL-Go System Files
Unexpected error when running action. Error Message: The remote server returned an error: (404) Not Found.   Not Found , StackTrace: at GetLatestTemplateSha, D:\a\_actions\microsoft\AL-Go-Actions\v7.0\CheckForUpdates\CheckForUpdates.HelperFunctions.ps1: line 68 <- at DownloadTemplateRepository, D:\a\_actions\microsoft\AL-Go-Actions\v7.0\CheckForUpdates\CheckForUpdates.HelperFunctions.ps1: line 30 <- at <ScriptBlock>, D:\a\_actions\microsoft\AL-Go-Actions\v7.0\CheckForUpdates\CheckForUpdates.ps1: line 80 <- at <ScriptBlock>, D:\a\_temp\f779af73-a2fe-4748-ad10-1dda827abea8.ps1: line 3 <- at <ScriptBlock>, D:\a\_actions\microsoft\AL-Go-Actions\v7.0\Invoke-AlGoAction.ps1: line 17 <- at <ScriptBlock>, D:\a\_temp\f779af73-a2fe-4748-ad10-1dda827abea8.ps1: line 2 <- at <ScriptBlock>, <No file>: line 1

Looking into AL-Go-Actions\v7.0\CheckForUpdates\CheckForUpdates.HelperFunctions.ps1:

    # Construct API URL
    $apiUrl = $templateUrl.Split('@')[0] -replace "^(https:\/\/github\.com\/)(.*)$", "$ENV:GITHUB_API_URL/repos/`$2"

You can see that it only handles github.com and not ghe.com domains.

I have tried with forking the template repository inside our enterprise and updating the settings in AL-Go-Settings.json:

"templateUrl": "https://companyname.ghe.com/companyname-ext/shared-template-AL-Go-AppSource@main",
 "customGitHubApiUrl": "https://companyname.ghe.com/api/v3",
 "customGitHubGraphQlUrl": "https://companyname.ghe.com/api/graphql"

And adding a PAT/Apps to our repository (GhTokenWorkflow), this generate other errors again:

 [main] Update AL-Go System Files
Unexpected error when running action. Error Message: Failed to update AL-Go System Files. Could not get the latest SHA from template (https://companyname.ghe.com/companyname-ext/shared-template-AL-Go-AppSource@main). (Error was The remote server returned an error: (406) Not Acceptable. Not Acceptable ), StackTrace: at GetLatestTemplateSha, D:\a\_actions\microsoft\AL-Go-Actions\v8.0\CheckForUpdates\CheckForUpdates.HelperFunctions.ps1: line 79 <- at DownloadTemplateRepository, D:\a\_actions\microsoft\AL-Go-Actions\v8.0\CheckForUpdates\CheckForUpdates.HelperFunctions.ps1: line 53 <- at <ScriptBlock>, D:\a\_actions\microsoft\AL-Go-Actions\v8.0\CheckForUpdates\CheckForUpdates.ps1: line 70 <- at <ScriptBlock>, D:\a\_temp\b5320c6c-81cb-4947-ab8b-ef3311679d0f.ps1: line 3 <- at <ScriptBlock>, D:\a\_actions\microsoft\AL-Go-Actions\v8.0\Invoke-AlGoAction.ps1: line 21 <- at <ScriptBlock>, D:\a\_temp\b5320c6c-81cb-4947-ab8b-ef3311679d0f.ps1: line 2 <- at <ScriptBlock>, <No file>: line 1

These are just finding in one workflow, we have not tried much other workflows.

[RyanAtMicroChannel]

Looks like I was just posting about a similar topic : #2002.

As what I also suspect is that we are going to have to handle the APIs for GHE a bit differently as the expect different headers.

Right now, I think we will struggle a bit unless we can somehow update the actions to handle GHE.

From my post we would need to at least update the some of the helper functions in PowerShell. For example, make a change to GetHeaders function in GitHub-Helper.psm1 to detect if we are on GitHub Enterprise and use the headers it expects for API calls.

Co-Pilot suggests something like this : -

    # Decide whether this is GitHub.com or GHES
    $isGitHubCom = $false
    try {
        if (-not [string]::IsNullOrEmpty($api_url)) {
            $u = [uri]$api_url
            if ($u.Host -ieq "api.github.com") {
                $isGitHubCom = $true
            }
        }
    } catch {
        # If parsing fails, fallback to assuming GitHub.com behavior
        $isGitHubCom = $true
    }

    # For GHES, prefer the v3 Accept header and DO NOT send X-GitHub-Api-Version
    if ($isGitHubCom) {
        $headers = @{
            "Accept" = $accept
            "X-GitHub-Api-Version" = $apiVersion
        }
    }
    else {
        # GitHub Enterprise Server: use v3 Accept and omit the API version header
        $headers = @{
            "Accept" = "application/vnd.github.v3+json"
        }
    }