{"id":15012262,"url":"https://github.com/microsoft/mu_devops","last_synced_at":"2025-06-19T07:40:05.180Z","repository":{"id":61724678,"uuid":"529390853","full_name":"microsoft/mu_devops","owner":"microsoft","description":"Project Mu Developer Operations","archived":false,"fork":false,"pushed_at":"2025-03-28T20:26:39.000Z","size":698,"stargazers_count":31,"open_issues_count":13,"forks_count":25,"subscribers_count":6,"default_branch":"main","last_synced_at":"2025-03-30T21:38:40.865Z","etag":null,"topics":["continuous-integration","firmware","projectmu","uefi","uefi-development"],"latest_commit_sha":null,"homepage":"https://microsoft.github.io/mu/","language":"Dockerfile","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/microsoft.png","metadata":{"files":{"readme":"ReadMe.rst","changelog":null,"contributing":null,"funding":null,"license":"LICENSE.txt","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":"SECURITY.md","support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2022-08-26T20:05:22.000Z","updated_at":"2025-03-28T20:26:43.000Z","dependencies_parsed_at":"2024-01-22T23:48:58.086Z","dependency_job_id":"8ff8f6fc-4a5d-4a46-9a5c-7c37e19b8ec1","html_url":"https://github.com/microsoft/mu_devops","commit_stats":{"total_commits":351,"total_committers":16,"mean_commits":21.9375,"dds":"0.41880341880341876","last_synced_commit":"e6710ae7fd59d4dc54fc6b6f18cc04ae52a8d693"},"previous_names":[],"tags_count":114,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/microsoft%2Fmu_devops","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/microsoft%2Fmu_devops/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/microsoft%2Fmu_devops/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/microsoft%2Fmu_devops/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/microsoft","download_url":"https://codeload.github.com/microsoft/mu_devops/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":246927835,"owners_count":20856198,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["continuous-integration","firmware","projectmu","uefi","uefi-development"],"created_at":"2024-09-24T19:42:20.397Z","updated_at":"2025-04-03T03:11:02.868Z","avatar_url":"https://github.com/microsoft.png","language":"Dockerfile","funding_links":[],"categories":[],"sub_categories":[],"readme":"===================================================\nProject Mu Developer Operations (DevOps) Repository\n===================================================\n\n|Latest Mu DevOps Release Version (latest SemVer)| |Commits Since Last Release| |Sync Mu DevOps Files to Mu Repos| |Containers Build|\n\n.. |Latest Mu DevOps Release Version (latest SemVer)| image:: https://img.shields.io/github/v/release/microsoft/mu_devops?label=Latest%20Release\n   :target: https://github.com/microsoft/mu_devops/releases/latest\n\n.. |Commits Since Last Release| image:: https://img.shields.io/github/commits-since/microsoft/mu_devops/latest/main?include_prereleases\n   :target: https://github.com/microsoft/mu_devops/releases\n\n.. |Sync Mu DevOps Files to Mu Repos| image:: https://github.com/microsoft/mu_devops/actions/workflows/FileSyncer.yml/badge.svg\n   :target: https://github.com/microsoft/mu_devops/actions/workflows/FileSyncer.yml\n\n.. |Containers Build| image:: https://github.com/microsoft/mu_devops/actions/workflows/Build-Containers.yml/badge.svg?branch=main\n   :target: https://github.com/microsoft/mu_devops/actions/workflows/Build-Containers.yml\n\nThis repository is part of Project Mu.  Please see Project Mu for details https://microsoft.github.io/mu\n\nThis repository is used to manage files related to build, continuous integration (CI), and continuous deployment (CD)\nfor other Project Mu repositories.\n\nMany of these files are generic YAML templates that can be combined together to compose a fully functional pipeline.\n\nPython based code leverages `edk2-pytools` to support cross platform building and execution.\n\nYou can find a high-level summary of the latest changes since the last release by viewing the `latest draft release`_.\n\n.. _`latest draft release`: https://github.com/microsoft/mu_devops/releases\n\nTable of Contents\n=================\n\n1. `Project Mu Developer Operations (DevOps) Repository`_\n\n2. `Table of Contents`_\n\n3. `Continuous Integration (CI)`_\n\n   - `Code Coverage`_\n\n4. `Conventions`_\n\n5. `Containers`_\n\n6. `GitHub Automation Workflow Overview`_\n\n   - `Leaf Workflows \u0026 Reusable Workflows`_\n\n   - `Reusable Workflows`_\n\n   - `Leaf Workflows`_\n\n7. `GitHub Automation Workflow Summary`_\n\n   - `Auto Merge`_\n\n   - `Auto Approver`_\n\n   - `File Synchronization`_\n\n   - `Initial Issue Triage`_\n\n   - `Issue Assignment`_\n\n   - `Label Automation`_\n\n   - `Pull Request Validator`_\n\n   - `Release Drafting`_\n\n   - `Scheduled Maintenance`_\n\n   - `Stale Detection`_\n\n8. `GitHub Action Summary`_\n\n   - `Submodule Release Updater`_\n\n9. `Steps for Updating Rust Tool Chain`_\n\n10.  `Links`_\n\nContinuous Integration (CI)\n===========================\n\nThere are two broad categories of CI - Core CI and Platform CI. You may see these terms used in the repo.\n  - **Core CI** - Focused on building and testing all packages in Edk2 without an actual target platform.\n  - **Platform CI** - Focused on building a single target platform and confirming functionality on that platform.\n\nCode Coverage\n-------------\n\nmu_devops provides azure pipeline templates for uploading code coverage to the pipline currently executing, or directly\nto codecov.io for public github repositories that use azure pipelines. No matter the yaml file you are using, whether\nit be `MuDevOpsWrapper.yml`, `Jobs/PrGate.yml`, `Steps/PrGate.yml` or `Steps/UploadCodeCoverage.yml` itself, the only a\naction that needs to be taken is to set an environment variable `coverage_upload_target` to ado or codecov.\n\nConventions\n===========\n\n- Shared templates in Project Mu repos are encouraged to be maintained in this repository.\n\n- The `.github` directory contains GitHub collateral for this repository.\n\n  - Some of the files are shared GitHub actions or workflows used (referenced) by other repositories as well.\n\n- Files that are synced to other repositories should be placed in the `.sync` folder.\n\n  - Some files are synced back to this repository (`mu_devops`).\n\n- Azure Pipelines job and step templates should respectively be placed in the `Jobs` and `Steps` directories.\n\n- YAML files should have the extensions `*.yml`.\n\n  - An exception is the markdown configuration file (`.markdownlint.yaml`) that uses `.yaml` for consistency with\n    pre-existing conventions across Mu repos.\n\nContainers\n==========\n\nThis repo maintains containers used throughout Project Mu projects. Containers provide well-defined, ready-to-go\nimages and result in improved performance, portability, and consistency of build environments. Project Mu leverages\ncontainers for both server-side builds (e.g. pull requests and continuous integration) and for local developer builds.\n\nAt this time, containers are only offered for Linux. If you want to get started quickly and receive the smoothest\nbuild experience, it is recommended to use containers where available.\n\nThe `Containers` directory contains the actual dockerfiles for building the containers. The containers are actually\nbuilt (in pull requests to dockerfiles and merges to the `main` branch) in the `.github/workflows/Build-Containers.yml`\nworkflow. On any change to a dockerfile a new container is built and pushed to the Microsoft GitHub container registry\nas a container package associated with this repo. The latest Project Mu container builds are available in the\n`Packages - Mu DevOps`_ container feed and more information is available in the `Container Readme file`_.\n\n.. _`Container Readme file`: https://github.com/microsoft/mu_devops/blob/main/Containers/Readme.md\n.. _`Packages - Mu DevOps`: https://github.com/orgs/microsoft/packages?repo_name=mu_devops\n\nGitHub Automation Workflow Overview\n===================================\n\nThis repository also drives automation of Project Mu GitHub repositories.\n\nLeaf Workflows \u0026 Reusable Workflows\n-----------------------------------\n\nWorkflows are split into two categories **(1) leaf** and **(2) reusable**.\n\nThe main reason for reusable workflows is to consolidate the main logic for the workflow to a single file and allow\nthe leaf workflow to be present in repositories that opt into what the reusable workflow provides. Leaf workflows can\nprovide any repo-specific input to a reusable workflow (if necessary). Leaf workflows can be considered minimal\nwrappers around reusable workflows.\n\nReusable Workflows\n------------------\n\nThese workflow are only designed to be called from other workflows. The files are maintained in the `.github/workflows`\ndirectory of this repository. This is mandatory as GitHub only allows leaf workflows to call reusable workflows\nlocated in this directory.\n\nReview reusable workflow files to understand what they do and what input parameters are available.\n\nLeaf Workflows\n------------------\n\nThese workflow are only designed to call reusable workflows. They should not directly invoke GitHub Actions. The\nactual GitHub Actions used by Project Mu are centrally tracked/updated in the single-copy reusable workflow files\nin the Mu DevOps repo. This allows dependabot to update the actions here at once.\n\nGitHub Automation Workflow Summary\n==================================\n\nFollowing is a brief summary of the actual workflows in the repository.\n\nAuto Merge\n----------\n\nAs automated bots pick up mundane tasks like syncing PIP module updates, submodules, files, and so on, an increasing\nnumber of pull requests can accumulate that essentially update dependencies we expect to be updated over time. In most\ncases, we simply care that the new update passes CI checks.\n\nTherefore, Project Mu repos auto merge certain pull requests to reduce human burden of approving these requests in all\nof the Project Mu repos. Individual repos can opt out of this functionality by removing the leaf workflow sync to their\nrepo, however, it is recommended to keep this flow enabled for consistency across all repos.\n\nTo see more about this flow look in these files:\n\n- The main reusable workflow file:\n\n  - `.github/workflows/AutoMerger.yml`\n\n- The leaf workflow\n\n  - `.sync/workflows/leaf/auto-merge.yml`\n\nA Project Mu repo simply needs to sync `.sync/workflows/leaf/auto-merge.yml` to their repo in `Files.yml` and the\nauto merge workflow will run in the repo.\n\nAuto Approver\n-------------\n\nAuto approves pull requests from allowed bot accounts. As part of reducing dependency overhead, this workflow first\napproves pull requests that are then auto merged after CI status checks complete. If a CI status check (e.g. build)\nfails, the pull request will not be merged.\n\nNote: This is currently disabled in most Project Mu repos.\n\nTo see more about this flow look in these files:\n\n- The main reusable workflow file:\n\n  - `.github/workflows/AutoApprover.yml`\n\n- The leaf workflow\n\n  - `.sync/workflows/leaf/auto-approve.yml`\n\nA Project Mu repo simply needs to sync `.sync/workflows/leaf/auto-approve.yml` to their repo in `Files.yml` and the\nauto approve workflow will run in the repo.\n\nFile Synchronization\n--------------------\n\nBecause Project Mu is distributed over many repositories, a need arises to sync common files across all of the repos.\nThis is done via the `.github/workflows/FileSyncer.yml` workflow in Mu DevOps. It determines how to map files from\nMu DevOps to any repo with the configuration file `.sync/Files.yml`.\n\nThe configuration file can map any file in Mu DevOps to any file path in a destination repo. Flexibility is provided\nto map the same file to different file paths in different repos, not map the file to some repos, etc. Whole directories\ncan also be synced as well.\n\nThe file sync operation automatically runs anytime a file in the `.sync/` directory of Mu DevOps is updated.\n\nThe file modification flow should be as follows:\n\n1. Developer updates a synced file in Mu DevOps\n2. Once PR for (1) is merged all mapped repos get a PR with the change\n3. Reviewers in each repo review and approve the PR\n4. The file is now in sync across all repos\n\nFile synchronization PRs are created by the `Project Mu UEFI Bot`_ account.\n\nThe file synchronization process will use the original commit title and message when syncing the change if it is\ntriggered on a single commit. Therefore, it is recommended to make changes to sync files one file per commit at a\ntime. If more than one file is modified, the PR is simply a single commit with a generic message containing both\nchanges.\n\n.. _`Project Mu UEFI Bot`: https://github.com/uefibot\n\nInitial Issue Triage\n--------------------\n\nThis repo syncs `GitHub issue form templates`_ to many Project Mu repos. Part of initial triage for incoming issues\ninvolves parsing data in the issue form to apply the appropriate labels so the issue is ready for triage by a human.\n\nIssues need to be triaged by a human when the `state:needs-triage` label is present. This workflow can parse details\nprovided in issue forms to apply additional labels. For example, the `state:needs-owner` label is applied if the user\nindicates they are not fixing the issue, the `urgency:\u003clevel\u003e` label is applied based on user selection in the urgency\ndropdown, etc.\n\nA Project Mu repo simply needs to sync `.sync/workflows/leaf/triage-issues.yml` to their repo and the issue triage\nworkflow will run in the repo.\n\n.. _`GitHub issue form templates`: https://github.com/microsoft/mu_devops/tree/main/.sync/github_templates/ISSUE_TEMPLATE\n\nThis workflow works in concert with other issue workflows such as `.sync/workflows/leaf/issue-assignment.yml` to\nautomate labels in issues based on the state of the issue.\n\nIssue Assignment\n----------------\n\nA generic workflow that contains actions applied when GitHub issues are assigned. Currently, the workflow removes\nlabels from the issue that are no longer relevant after it is assigned.\n\nTo see more about this flow look in these files:\n\n- The main reusable workflow file:\n\n  - `.github/workflows/IssueAssignment.yml`\n\n- The leaf workflow\n\n  - `.sync/workflows/leaf/issue-assignment.yml`\n\nLabel Automation\n----------------\n\nLabels are automated from this repo in two main ways:\n\n1. Automatically synchronize labels across all Project Mu repos\n2. Automatically apply labels to issues and PRs\n\n(1) is provided via the `.github/workflows/LabelSyncer.yml` reusable workflow with the labels defined in the file\n`.github/Labels.yml`.\n\n(2) is provided via the `.github/workflows/Labeler.yml` reusable workflow with the labeling configuration defined in\n`.sync/workflows/config/label-issues`.\n\nLabels are synced to all repos on a regular schedule that is the same for all repos.\n\nLabels are automatically applied to issues and pull request on creation/modification and can be applied based on file\npaths modified a pull request or content in the body of the issue or pull request.\n\nPull Request Validator\n----------------------\n\nValidates pull request formatting against requirements defined in the workflow. This workflow is not intended to\nstrictly validate exact formatting details but provide hints when simple, broad changes are needed to enhance the\nquality of pull request verbiage.\n\n- The leaf workflow\n\n  - `.sync/workflows/leaf/pull-request-formatting-validator.yml`\n\nRelease Drafting\n----------------\n\nIn order to ensure semantic versioning is followed based on well-defined labels used in Project Mu pull requests, the\nrelease drafting process is automated. On every PR merge, a draft release is updated that contains the PR change entry\ncategorized according to the labels with the semantic version of the draft release updated according to the semantic\nversion specification.\n\nThis means, that the details for an upcoming release are always available, the release format is consistent across\nProject Mu repos, and semantic versioning is followed consistently.\n\nThe draft release should be converted to an actual release any time the minor or major version is updated by a change.\n\nTo see more about this flow look in these files:\n\n- The main reusable workflow file:\n\n  - .github/workflows/ReleaseDrafter.yml\n\n- The configuration file for the reusable workflow:\n\n  - .sync/workflows/config/release-draft/release-draft-config.yml\n\n    - This will be synced to .github/release-draft-config.yml in repos using release drafter\n\nA Project Mu repo simply needs to sync `.sync/workflows/leaf/release-draft.yml` and the config file\n`.sync/workflows/config/release-draft/release-draft-config.yml` to their repo and adjust any parameters needed in the\nsync process (like repo default branch name) and the release draft workflow will run in the repo.\n\nScheduled Maintenance\n---------------------\n\nPerforms regularly scheduled maintenance-related tasks such as closing pull requests and issues marked stale. Similar\ntasks can be added to the workflow over time.\n\nThe leaf workflow contains the primary implementation and is directly synced to subscribed repos:\n\n- `.sync/workflows/leaf/scheduled-maintenance.yml`\n\nStale Detection\n---------------\n\nStale issues and pull requests are automatically labeled and closed after a configured amount of time.\n\nThis is provided by the `.github/workflows/Stale.yml` reusable workflow.\n\nIndividual repositories can control the label and time settings but it is strongly recommended to use the default\nvalues defined in the reusable workflow for consistency.\n\nGitHub Action Summary\n=====================\n\nFollowing is a brief summary of the GitHub Actions maintained in the repository.\n\nSubmodule Release Updater\n-------------------------\n\nA GitHub Action and leaf workflow that automatically create a pull request for any submodule in a repo\nthat has a new GitHub release available. The leaf workflow can easily be synced to repos and wraps around\nthe GitHub action.\n\n- The GitHub action\n\n  - `.github/actions/submodule-release-updater`\n\n- The leaf workflow\n\n  - `.sync/workflows/leaf/submodule-release-update.yml`\n\nSteps for Updating Rust Tool Chain\n=====================\n\nSteps required to update the Rust tool chain in the Mu DevOps repo. The steps are as follows:\n\n1. Update rust_toolchain in .sync/Version.njk to the new version. PR and merge to main.\n2. Run Build Containers workflow to build a new linux container image (which will use updated .sync/Version.njk).\n3. Update linux_build_container in .sync/Version.njk with the new version. PR and merge to main.\n4. Create new mu_devops tag (GitHub release).\n5. Update mu_devops in .sync/Version.njk to the newly generated tag. PR and merge to main.\n6. Run Sync Mu DevOps Files to Mu Repos workflow to sync the new version to all Mu repos.\n7. Complete associated PRs in the Mu repos.\n\nLinks\n=====\n- `Basic Azure Landing Site \u003chttps://docs.microsoft.com/en-us/azure/devops/pipelines/?view=azure-devops\u003e`_\n- `Pipeline jobs \u003chttps://docs.microsoft.com/en-us/azure/devops/pipelines/process/phases?view=azure-devops\u0026tabs=yaml\u003e`_\n- `Pipeline YAML scheme \u003chttps://docs.microsoft.com/en-us/azure/devops/pipelines/yaml-schema?view=azure-devops\u0026tabs=schema%2Cparameter-schema\u003e`_\n- `Pipeline Expressions \u003chttps://docs.microsoft.com/en-us/azure/devops/pipelines/process/expressions?view=azure-devops\u003e`_\n- `PyTool Extensions \u003chttps://github.com/tianocore/edk2-pytool-extensions\u003e`_\n- `PyTool Library \u003chttps://github.com/tianocore/edk2-pytool-library\u003e`_\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmicrosoft%2Fmu_devops","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmicrosoft%2Fmu_devops","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmicrosoft%2Fmu_devops/lists"}