GitHub

@@ -4,14 +4,14 @@ titleSuffix: Microsoft Sentinel description: This article describes how to customize repository deployments for the repositories feature in Microsoft Sentinel. author: mberdugo  ms.topic: how-to-ms.date: 06/15/2026+ms.date: 07/01/2026 ms.author: monaberdugo  appliesto:     - Microsoft Sentinel in the Microsoft Defender portal     - Microsoft Sentinel in the Azure portal ms.collection: usx-security ai-usage: ai-assisted-ms.custom: msecd-doc-authoring-1014+ms.custom: msecd-doc-authoring-1016  #Customer intent: As a SOC collaborator or MSSP analyst, I want to customize repository deployment workflows and pipelines so that I can control deployment triggers, paths, and parameter mappings for efficient and tailored content deployment to cloud workspaces. @@ -39,13 +39,13 @@ For more information on deployable content types, see [Plan your repository cont  ## Customize the workflow or pipeline -The default workflow only deploys content modified since the last deployment, based on commits to the repository. Customize to configure different deployment triggers, or to deploy content exclusively from a specific root folder.+The default workflow only deploys content modified since the last deployment, based on commits to the repository. Customize the workflow or pipeline to configure different deployment triggers, or to deploy content exclusively from a specific root folder.  Select one of the following tabs depending on your connection type:  # [GitHub](#tab/github) -**To customize your GitHub deployment workflow**:+To customize your GitHub deployment workflow:  1. In GitHub, go to your repository and find your workflow in the *.github/workflows* directory. @@ -55,7 +55,7 @@ Select one of the following tabs depending on your connection type:  1. Select the pencil button at the top-right of the page to open the file for editing, and then modify the deployment as follows: -    - **To modify the deployment trigger**, update the `on` section in the code, which describes the event that triggers the workflow to run.+    - To modify the deployment trigger, update the `on` section in the code, which describes the event that triggers the workflow to run.          By default, this configuration is set to `on: push`, which means that the workflow is triggered at any push to the connected branch, including both modifications to existing content and additions of new content to the repository. For example: @@ -71,18 +71,19 @@ Select one of the following tabs depending on your connection type:          Change these settings, for example, to schedule the workflow to run periodically, or to combine different workflow events together. -        For more information, see the [GitHub documentation](https://docs.github.com/en/actions/learn-github-actions/events-that-trigger-workflows#configuring-workflow-events) on configuring workflow events.+        For more information, see [Configuring workflow events](https://docs.github.com/en/actions/learn-github-actions/events-that-trigger-workflows#configuring-workflow-events) in the GitHub documentation.++    - To disable smart deployments: -    - **To disable smart deployments**:         Smart deployment behavior is configured separately from the workflow trigger in the `on` section. Navigate to the `jobs` section of your workflow. Switch the `smartDeployment` default value from `true` to `false`. Once this change is committed, the smart deployment functionality is turned off, and all future deployments for this connection redeploy all the repository's relevant content files to the connected workspaces.  -    - **To modify the deployment path**:+    - To modify the deployment path:          In the default configuration shown for the `on` section, the wildcards (`**`) in the first line in the `paths` section indicate that the entire branch is in the path for the deployment triggers. -        This default configuration means that a deployment workflow is triggered anytime that content is pushed to any part of the branch.+        This default configuration means that a deployment workflow is triggered anytime that content is pushed to any part of the connected branch. -        Later on in the file, the `jobs` section includes the following default configuration: `directory: '${{ github.workspace }}'`. This line indicates that the entire GitHub branch is in the path for the content deployment, without filtering for any folder paths.+        In the `jobs` section, the default configuration includes `directory: '${{ github.workspace }}'`. The `directory` setting indicates that the entire GitHub branch is in the path for the content deployment, without filtering for any folder paths.          To deploy content from a specific folder path only, add it to both the `paths` and the `directory` configuration. For example, to deploy content only from a root folder named `SentinelContent`, update your code as follows: @@ -96,11 +97,11 @@ Select one of the following tabs depending on your connection type:             directory: '${{ github.workspace }}/SentinelContent'         ``` -For more information, see the [GitHub documentation](https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#onpushpull_requestpaths) on GitHub Actions and editing GitHub workflows.+For more information, see [GitHub Actions workflow syntax for path filters](https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#onpushpull_requestpaths) in the GitHub documentation.  # [Azure DevOps](#tab/azure-devops) -**To customize your Azure DevOps deployment pipeline**:+To customize your Azure DevOps deployment pipeline:  1. In Azure DevOps, go to your repository and find your pipeline definition file in the *.sentinel* directory. @@ -110,16 +111,16 @@ For more information, see the [GitHub documentation](https://docs.github.com/en/  1. Select the pencil button at the top-right of the page to open the file for editing, and then modify the deployment as follows: -    - **To modify the deployment trigger**, update the `trigger` section in the code, which describes the event that triggers the workflow to run.+    - To modify the deployment trigger, update the `trigger` section in the code, which describes the event that triggers the workflow to run.          By default, this configuration is set to detect any push to the connected branch, including both modifications to existing content and additions of new content to the repository. -        Modify this trigger to any available Azure DevOps Triggers, such as a scheduling trigger or a pull request triggers. For more information, see the [Azure DevOps trigger documentation](/azure/devops/pipelines/yaml-schema).+        Modify this trigger to any available Azure DevOps Triggers, such as a scheduling trigger or a pull request triggers. For more information, see the [Azure DevOps YAML pipeline schema](/azure/devops/pipelines/yaml-schema). -    - **To disable smart deployments**:+    - To disable smart deployments:         Smart deployment behavior is configured separately from the pipeline trigger in the `trigger` section. Navigate to the `ScriptArguments` section of your pipeline. Switch the `smartDeployment` default value from `true` to `false`. Once this change is committed, smart deployment functionality is turned off, and all future deployments for this connection redeploy all the repository's relevant content files to the connected workspaces.  -    - **To modify the deployment path**:+    - To modify the deployment path:          The default configuration for the `trigger` section has the following code, which indicates that the `main` branch is in the path for the deployment triggers: @@ -130,7 +131,7 @@ For more information, see the [GitHub documentation](https://docs.github.com/en/                 - main         ``` -        This default configuration means that a deployment pipeline is triggered anytime that content is pushed to any part of the `main` branch.+        The default `trigger` configuration means that a deployment pipeline is triggered anytime that content is pushed to any part of the `main` branch.          To deploy content from a specific folder path only, add the folder name to the `include` section for the trigger and the deployment path to the `steps` section. @@ -151,20 +152,19 @@ For more information, see the [GitHub documentation](https://docs.github.com/en/             workingDirectory: `SentinelContent`         ``` -For more information, see the [Azure DevOps documentation](/azure/devops/pipelines/yaml-schema) on the Azure DevOps YAML schema.+For more information, see the [Azure DevOps YAML pipeline schema](/azure/devops/pipelines/yaml-schema).  ---  > [!IMPORTANT] > In both GitHub and Azure DevOps, make sure that you keep the trigger path and deployment path directories consistent.->  ## Scale your deployments with parameter files -Rather than passing parameters as inline values in your content files, consider [using a Bicep parameter file](/azure/azure-resource-manager/bicep/parameter-files) or a [JSON file that contains the parameter values](/azure/azure-resource-manager/templates/parameter-files). Then map those parameter files to their associated Microsoft Sentinel content files to better scale your deployments across different workspaces. +Rather than passing parameters as inline values in your content files, consider [using a Bicep parameter file](/azure/azure-resource-manager/bicep/parameter-files) or a [JSON file that contains the parameter values](/azure/azure-resource-manager/templates/parameter-files). Then map those parameter files to their associated Microsoft Sentinel content files to better scale your deployments across different workspaces.++There are several ways to map parameter files to the content files. Keep in mind, Bicep parameter files only support Bicep file templates, but JSON parameter files support both. The repositories deployment pipeline considers parameter files in the following order: -There are several ways to map parameter files to the content files. Keep in mind, Bicep parameter files only support Bicep file templates, but JSON parameter files support both. The repositories deployment pipeline considers parameter files in the following order: -  :::image type="content" source="media/ci-cd-custom-deploy/deploy-parameter-file-precedence-with-bicep.svg" alt-text="A diagram showing the precedence of parameter file mappings.":::  1. Is there a mapping in the *sentinel-deployment.config*?</br>For more information, see [Customize your connection configuration](ci-cd-custom-deploy.md#customize-your-connection-configuration).@@ -176,12 +176,11 @@ There are several ways to map parameter files to the content files. Keep in mind 1. Is there a default parameter file? Yes, the content files are in the same directory with a parameter file matching one of these patterns:    </br>*.bicepparam*    </br>*.parameters.json*-     + Avoid clashes with multiple workspace deployments by mapping your parameter files through the configuration file or specifying the workspace ID in the file name.  > [!IMPORTANT] > Once a parameter file match is determined based on the mapping precedence, the pipeline ignores any remaining mappings.->   Modifying the mapped parameter file listed in the *sentinel-deployment.config* triggers the deployment of its paired content file. Adding or modifying a workspace-mapped parameter file or a default parameter file also triggers a deployment of the paired content files along with the newly modified parameters, unless a higher precedence parameter mapping is in place. Other content files aren't deployed as long as the smart deployments feature is still enabled in the workflow/pipeline definition file. @@ -225,27 +224,23 @@ Here's an example of the entire contents of a valid *sentinel-deployment.config*  > [!NOTE] > Don't use the backslash "\\" character in any of the content paths. Use the forward slash "/" instead.->  -- **To prioritize content files**:- +- To prioritize content files:+     As the amount of content in your repository grows, deployment times may increase. Add time sensitive content to this section to prioritize its deployment when a trigger occurs. -    +     Add full path names to the `"prioritizedcontentfiles":` section. Wildcard matching isn't supported at this time. -- **To exclude content files**, modify the `"excludecontentfiles":` section with full path names of individual .json content files.+- To exclude content files, modify the `"excludecontentfiles":` section with full path names of individual .json content files. -- **To map parameters**:+- To map parameters:      The deployment script accepts three methods of mapping parameters (configuration-file mappings, workspace-mapped parameter files, and default parameter files) as described in [Scale your deployments with parameter files](ci-cd-custom-deploy.md#scale-your-deployments-with-parameter-files). Mapping parameters through the *sentinel-deployment.config* takes the highest precedence and guarantees that a given parameter file is mapped to its associated content files. Modify the `"parameterfilemappings":` section with your target connection's workspace ID and full path names of individual .json files. - ## Related content -A sample repository is available demonstrating the deployment config file and all three parameter mapping methods. For more information, see [Microsoft Sentinel CICD repositories sample](https://github.com/SentinelCICD/RepositoriesSampleContent).-+- [Microsoft Sentinel CICD repositories sample](https://github.com/SentinelCICD/RepositoriesSampleContent). - [Understand the structure and syntax of Bicep files](/azure/azure-resource-manager/bicep/file) - [Parameters in Bicep](/azure/azure-resource-manager/bicep/parameters) - [Create Resource Manager parameter file](/azure/azure-resource-manager/templates/parameter-files) - [Parameters in ARM templates](/azure/azure-resource-manager/templates/parameters)-