| title | GitHub Actions Configuration | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| description | Configuration guide for GitHub Actions workflows and CI/CD setup for the Edge AI Accelerator repository | ||||||||||||||||
| author | Edge AI Team | ||||||||||||||||
| ms.date | 2025-06-06 | ||||||||||||||||
| ms.topic | hub-page | ||||||||||||||||
| estimated_reading_time | 7 | ||||||||||||||||
| keywords |
|
This repository can be cloned and used as the base image for an IaC repo with integrated CI/CD. There is minimal configuration required to enable the workflows, though fully automated, IaC-based setup is under design/construction.
This project follows a set of guiding principles for all development and automation:
- All IaC goes through a validation process on commit
- All IaC dependencies are monitored for outdated packages
- A reasonable effort will be made to test all IaC
- All Iac changes can be easily checked against
- empty environments
- QA and Integration Environments
- Pre-production environments, and
- Production Environments
- All IaC changes will produce detailed deployment plans for security reviews
- All IaC changes will use a decimal system for process organization
- All build processes will be built on each pull request
- Key build processes will be run on each merge to main
- All workflow components should be templatized for reuse and consistency
- Workflow templates should be modular and parameterized for flexibility and reuse
The build workflow provides several key features, with more on the way:
- Checks Terraform Provider versions for update opportunities and publishes build warning
- Runs a lightweight vulnerability scan for all dependant packages
- Runs file linting on a wide variety of languages and file types using MegaLinter
- Performs a matrix build on only resources that have been modified in the current PR
- Publishes Terraform Plans for all changed resources within the current PR
- Runs unit tests on changed Terraform within the current PR
- Provides modular, reusable workflow components for flexible workflow creation
- Ensures consistent validation steps across all workflows through shared components
- Enables PR comment integration for linting results through MegaLinter
- Optimizes workflow performance with intelligent caching mechanisms
The following sections will walk you through the process of configuring GitHub Actions for this repository.
Default practices for establishing connections between GitHub Actions and an Azure subscription is through the use of a Service Principal. Please follow the Azure documentation for creating a GitHub Action Authentication in your subscription, before proceeding. We recommend using contributor rights until further, fine-grained access guidance is added to this repository.
After creating the service principal, you'll need to store the credentials as GitHub Secrets:
- Navigate to your GitHub repository
- Go to "Settings" → "Secrets and variables" → "Actions"
- Add the following secrets:
AZURE_CLIENT_ID: The Application (client) ID of the service principalAZURE_TENANT_ID: The Azure tenant IDAZURE_SUBSCRIPTION_ID: The Azure subscription IDAZURE_CLIENT_SECRET: The service principal's client secret
This repository implements a modular approach to workflow definitions. Instead of monolithic workflow files, we break down common tasks into reusable components that can be combined in different ways. This approach provides several benefits:
- Consistency: Ensures the same validation steps are applied across all workflows
- Maintainability: Changes to a workflow component only need to be made in one place
- Reusability: Common tasks can be easily reused across different workflows and copied/referenced for additional projects
- Flexibility: Components can be parameterized for different scenarios
The repository includes two primary workflows that orchestrate the overall CI/CD process:
| Workflow | Trigger | Purpose |
|---|---|---|
main.yml |
Push to main branch, manual trigger | Complete validation and deployment to environments |
pr-validation.yml |
Pull requests to main branch | Validates changes before merging to ensure code quality |
These core workflows typically call the template workflows above in a specific sequence, providing a comprehensive validation and deployment process.
The following reusable template workflows are available in the .github/workflows directory:
| Workflow | Purpose | Documentation |
|---|---|---|
aio-version-checker.yml |
Checks component versions against latest available releases | Workflow Documentation |
cluster-test-terraform.yml |
Performs comprehensive testing of Terraform modules against real clusters | Workflow Documentation |
docs-check-bicep.yml |
Validates documentation quality including Bicep docs and URL checks | Workflow Documentation |
docs-check-terraform.yml |
Validates documentation quality including Terraform docs and URL checks | Workflow Documentation |
matrix-folder-check.yml |
Creates dynamic matrices of changed folders for downstream jobs | Workflow Documentation |
megalinter.yml |
Provides linting capabilities across multiple languages and file formats | Workflow Documentation |
pages-deploy.yml |
Deploys documentation to GitHub Pages | Workflow Documentation |
resource-provider-pwsh-tests.yml |
Validates Azure resource provider registration scripts | Workflow Documentation |
variable-compliance-bicep.yml |
Ensures consistent Bicep variable definitions across modules | Workflow Documentation |
variable-compliance-terraform.yml |
Ensures consistent Terraform variable definitions across modules | Workflow Documentation |
Note: All workflow documentation follows a standardized format that includes overview, features, parameters, usage examples, implementation details, and troubleshooting sections. This consistent structure makes it easier to learn and use the workflows effectively.
The repository includes two primary workflows that orchestrate the overall CI/CD process:
| Workflow | Trigger | Purpose | Documentation |
|---|---|---|---|
main.yml |
Push to main branch, manual trigger | Complete validation and deployment to environments | Workflow Documentation |
pr-validation.yml |
Pull requests to main branch | Validates changes before merging to ensure code quality | Workflow Documentation |
To maintain consistency across all workflow documentation, this repository includes a standardized documentation template. This template serves several important purposes:
- Provides a uniform structure for all workflow documentation
- Ensures comprehensive coverage of essential information (inputs, outputs, examples, etc.)
- Makes it easier for new team members to understand how GitHub Actions workflows work
- Helps GitHub Copilot generate properly formatted documentation when assisting with updates
When creating documentation for a new workflow or updating existing workflow documentation:
- Use the
workflow-template.mdas a starting point - Replace the placeholder content with information specific to your workflow
- Maintain the standardized formatting, especially for inputs and outputs tables
- Include all relevant sections (Overview, Features, Inputs, Outputs, etc.)
This standardized approach significantly improves documentation quality and helps users find the information they need quickly and consistently across all workflows.
The PR validation workflow is designed to:
- Validate code quality (linting, formatting)
- Check for security vulnerabilities
- Validate Terraform configurations
- Run tests on modified components
- Generate Terraform plans for review
This ensures that code changes meet quality standards before being merged to the main branch. The workflow posts results directly to the pull request, making the review process more efficient.
The main workflow is triggered when changes are merged to the main branch and handles:
- Running all validation checks on the integrated codebase
- Building necessary artifacts for deployment
- Deploying to development environments automatically (if configured)
- Preparing deployment plans for higher environments
- Optionally deploying to production environments (with approvals)
This workflow implements the continuous deployment aspect of the CI/CD pipeline, ensuring that validated changes can be reliably deployed to target environments.
GitHub Action workflows are defined in YAML files in the .github/workflows directory. They automatically run based on their configured triggers, such as push events or pull requests.
name: Linting
on:
pull_request:
branches: [ main ]
workflow_dispatch:
jobs:
megalinter:
name: MegaLinter
uses: ./.github/workflows/megalinter.yml
with:
github_comment_reporter: true
github_status_reporter: true
validate_all_codebase: ${{ github.event_name == 'push' && github.ref == 'refs/heads/main' }}
secrets: inheritThe following secrets are required/optional to run this repository's main workflows. Please see Using secrets in GitHub Actions for this process.
| Secret | Suggested value | Details |
|---|---|---|
AZURE_SUBSCRIPTION_ID |
Azure subscription GUID | Used for authenticating to Azure |
AZURE_CLIENT_ID |
Service Principal App ID | Used for authenticating to Azure |
AZURE_TENANT_ID |
Azure Tenant ID | Used for authenticating to Azure |
AZURE_CLIENT_SECRET |
Service Principal Secret | Used for authenticating to Azure |
TF_VAR_CUSTOM_LOCATIONS_OID |
OID of Arc Custom Location | Create and manage custom locations on Azure Arc-enabled Kubernetes |
The following environment variables can be configured in your workflows:
| Variable | Suggested value | Details |
|---|---|---|
TF_VAR_ENVIRONMENT |
prod |
e.g. dev, stage, prod |
TF_VAR_EXISTING_RESOURCE_GROUP |
build_system |
useful for integration environments |
TF_VAR_LOCATION |
westus |
Azure region to deploy to |
TF_VAR_RESOURCE_PREFIX |
build |
prefix for all created resources |
TF_VAR_VM_SKU_SIZE |
Standard_D8s_v3 |
VM Size |
TF_VAR_VM_USERNAME |
VM admin user name | Username for provisioned VMs |
- GitHub Actions Documentation
- Workflow Syntax for GitHub Actions
- Azure Login Action
- Terraform GitHub Actions
🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers.