Skip to main content
Secrets in AL-Go for GitHub are used to store sensitive information like authentication credentials, certificates, and tokens that your workflows need to access external resources securely.

​
Where Secrets are Defined

Secrets in GitHub can be defined at three different levels:

​
Organizational Secrets

Defined on your GitHub organization and can be shared with repositories in your organization.
For the free GitHub plan, organizational secrets can only be shared with public repositories.
Use cases:
  • Shared credentials across multiple repositories
  • Organization-wide Azure KeyVault access
  • Common AppSource delivery credentials

​
Repository Secrets

Defined on individual repositories. You can define any number of secrets on the repository.
If you define a secret at the repository level with the same name as an organizational secret, the repository secret overrides the organizational secret.
Use cases:
  • Repository-specific deployment credentials
  • Project-specific license files
  • Code signing certificates

​
Environment Secrets

Defined underneath a GitHub environment and only available to workflows during deployment to that environment.
For the free GitHub plan, environments (and environment secrets) are only available on public repositories.
Use cases:
  • Production deployment credentials
  • Environment-specific authentication contexts
  • Isolated secrets for different deployment targets

​
Azure KeyVault Integration

In AL-Go for GitHub, you can also define your secrets in an Azure KeyVault. You still need to create one secret in GitHub called Azure_Credentials to access the KeyVault.
See Azure KeyVault for detailed setup instructions.

​
Important Information About Secrets

Before creating secrets, read these important guidelines to avoid common mistakes:

​
Don’t Have Secrets That Are Not Secret

All secrets exposed to a repository are masked (replaced with ***) in workflow logs. However, if you create a secret with a value that’s not actually secret (like “windows”), it can break AL-Go functionality. Problem example: 
githubRunner: windows-latest
If you have a secret with value “windows”, GitHub will mask it in logs: 
githubRunner: ***-latest
This breaks core AL-Go functionality.
Only create secrets for values that are actually sensitive. Don’t create secrets for common words or configuration values.

​
Use Compressed JSON

AL-Go uses JSON structures for some secrets (like authentication contexts). When creating JSON structure secrets:
1

Compress the JSON

Always use compressed (single-line) JSON format
2

Avoid Multi-line Secrets

GitHub masks individual lines, which can break JSON structures
Incorrect (will break): 
{
  "prop": "value"
}
Correct: 
{"prop":"value"}
When using non-compressed JSON, GitHub masks the curly brackets { and } as separate secrets, breaking AL-Go.

​
Only Expose Necessary Secrets

If your GitHub organization has many organizational secrets:
Only allow access to secrets actually used by your AL-Go repository. If any exposed secrets contain multi-line content or non-secret values, it might break core AL-Go functionality.
Configure secret access in your repository settings under “Actions secrets and variables”.

​
List of Secrets

AL-Go for GitHub uses the following secrets:

Azure_Credentials

Connect to Azure resources and KeyVault

AuthContext

Deploy to Business Central environments

AppSourceContext

Deliver apps to Microsoft AppSource

StorageContext

Deliver artifacts to Azure Storage

GitHubPackagesContext

Deliver to GitHub Packages NuGet feed

NuGetContext

Deliver to NuGet feeds

GhTokenWorkflow

Update AL-Go System Files

GitSubmodulesToken

Access private Git submodules

LicenseFileUrl

Use specific license during CI/CD

​
Secret Naming Convention

Many AL-Go secrets can be customized using settings to specify the secret name:
​
licenseFileUrlSecretName
string
default:"LicenseFileUrl"
Name of the secret containing the license file URL
​
ghTokenWorkflowSecretName
string
default:"GhTokenWorkflow"
Name of the secret containing the GitHub token for workflow modifications
​
adminCenterApiCredentialsSecretName
string
default:"AdminCenterApiCredentials"
Name of the secret for Admin Center API credentials
​
applicationInsightsConnectionStringSecretName
string
default:"applicationInsightsConnectionString"
Name of the secret containing Application Insights connection string
​
codeSignCertificateUrlSecretName
string
default:"CodeSignCertificateUrl"
Name of the secret containing code signing certificate URL
​
codeSignCertificatePasswordSecretName
string
default:"CodeSignCertificatePassword"
Name of the secret containing code signing certificate password
​
storageContextSecretName
string
default:"StorageContext"
Name of the secret containing storage account context
​
appSourceContextSecretName
string
default:"AppSourceContext"
Name of the secret containing AppSource delivery context

​
Environment-Specific Secrets

When deploying to environments, AL-Go looks for environment-specific secrets: Pattern: <EnvironmentName>_AuthContext Examples:
  • Production_AuthContext - For Production environment
  • QA_AuthContext - For QA environment
  • Development_AuthContext - For Development environment
If an environment-specific secret doesn’t exist, AL-Go falls back to the generic AuthContext secret.

​
Creating Secrets in GitHub

1

Navigate to Settings

Go to your repository → Settings → Secrets and variables → Actions
2

Click New Secret

Choose “New repository secret” or “New environment secret”
3

Enter Name and Value

  • Name: Use the exact name AL-Go expects
  • Value: Paste the secret value (compressed JSON if applicable)
4

Save

Click “Add secret” to save

​
Security Best Practices

Store production credentials in environment secrets with required reviewers for additional security.
Regularly update secrets, especially for production environments and long-lived credentials.
For Azure resources, prefer managed identities with federated credentials over client secrets.
Only grant secrets access to repositories that need them.
Consider using Azure KeyVault for centralized secret management across multiple repositories.
Review workflow logs to ensure secrets are being used correctly and not exposed.

​
Testing Secret Configuration

After configuring secrets, test them by:
  1. Running the appropriate workflow (CI/CD, Deploy, etc.)
  2. Checking workflow logs for authentication success
  3. Verifying that masked values appear as *** in logs
  4. Confirming operations complete successfully
If a workflow fails due to authentication, check:
  • Secret name matches exactly (case-sensitive)
  • Secret value is correct and properly formatted
  • Secret is accessible to the repository/environment
  • For JSON secrets, ensure they are compressed

​
Next Steps

Explore detailed secret configuration:

Build docs developers (and LLMs) love

Get started for freeTalk to us