Modules/businessdev.ALbuild.Core/Private/Get-ALbuildConfigPath.ps1

function Get-ALbuildConfigPath {
    <#
    .SYNOPSIS
        Resolves the path of a persisted ALbuild configuration file.
 
    .DESCRIPTION
        Internal helper. ALbuild settings are MACHINE settings - cache folders, the AL Tool store, retry
        behaviour, licensing. On a build agent every account has to see the same ones, so the canonical
        store is machine-wide under the common application-data folder ('C:\ProgramData\ALbuild').
 
        A per-user file remains supported for a developer box, but it ranks BELOW the machine file (see
        Get-ALbuildConfig). It used to be the only store, and that caused a silent split: the agent account
        had 'G:\alb' in its own profile while an administrator on the same server read the built-in default
        'C:\alb' and saw a completely different cache. Nothing announced the divergence.
 
        ALBUILD_CONFIG still names one explicit file and then replaces the layering entirely - it is meant
        for tests and for pinning a config in an isolated run.
 
    .PARAMETER Scope
        Machine (default) - the shared file under the common application-data folder.
        User - the per-user file under the roaming application-data folder.
 
        ALBUILD_CONFIG, when set, overrides both.
    #>

    [CmdletBinding()]
    [OutputType([string])]
    param(
        [ValidateSet('Machine', 'User')]
        [string] $Scope = 'Machine'
    )

    if (-not [string]::IsNullOrWhiteSpace($env:ALBUILD_CONFIG)) {
        return $env:ALBUILD_CONFIG
    }

    # CommonApplicationData is 'C:\ProgramData' on Windows and '/usr/share' on Linux/macOS. ALbuild
    # already keeps machine-wide state there (container host shares), so agents need no new folder.
    $folder = if ($Scope -eq 'Machine') { 'CommonApplicationData' } else { 'ApplicationData' }
    $dir = Join-Path -Path ([System.Environment]::GetFolderPath($folder)) -ChildPath 'ALbuild'
    return Join-Path -Path $dir -ChildPath 'config.json'
}