diff --git a/.github/workflows/check-learning-path-links.yml b/.github/workflows/check-learning-path-links.yml new file mode 100644 index 00000000000..fd4ce368a75 --- /dev/null +++ b/.github/workflows/check-learning-path-links.yml @@ -0,0 +1,75 @@ +name: 'Check Learning Path Links' +on: + pull_request: + branches: ['main'] + +permissions: + pull-requests: read + +jobs: + check-learning-path-links: + name: 'Check Learning Path Links' + runs-on: ubuntu-latest + + steps: + - name: Checkout merge + uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab + with: + persist-credentials: false + path: merge + + - name: Checkout head + uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab + with: + persist-credentials: false + ref: main + path: head + + - name: Get base commit for the PR + working-directory: ./merge + run: | + git fetch origin "$GITHUB_BASE_REF" + base_sha=$(git rev-parse "origin/$GITHUB_BASE_REF") + echo "base_sha=$base_sha" >> $GITHUB_ENV + echo "Merging ${GITHUB_SHA} into ${GITHUB_BASE_REF}" + + - name: Get changed files + working-directory: ./merge + run: | + changed_source_files=$(git diff-tree --no-commit-id --name-only -r "$base_sha" "$GITHUB_SHA" | { grep "**.cs$" || test $? = 1; }) + echo "Files to validate: '${changed_source_files}'" + echo "updated_files=$(echo ${changed_source_files})" >> $GITHUB_ENV + + - name: Check Learning Path Links + id: check-links + uses: kkeirstead/LearningPathFileChecks@main + with: + repoURLToSearch: 'https://github.com/dotnet/dotnet-monitor' + learningPathsDirectory: 'documentation/learningPath' + paths: ${{ env.updated_files }} + + - name: Generate artifacts (Suggestion) + working-directory: ./merge + run: | + mkdir -p ./pr + cp "$GITHUB_EVENT_PATH" ./pr/pr-event.json + git diff > ./pr/linter.diff + + - name: Generate artifacts (Comment) + working-directory: ./merge + run: | + mkdir -p ./learning-path-review + echo -n "${{ steps.check-links.outputs.modifiedFiles }}" > ./learning-path-review/modifiedFiles + echo -n "${{ steps.check-links.outputs.manuallyReview }}" > ./learning-path-review/manuallyReview + + - name: Upload artifacts (Suggestion) + uses: actions/upload-artifact@a8a3f3ad30e3422c9c7b888a15615d19a852ae32 + with: + name: pr-linter + path: merge/pr/ + + - name: Upload artifacts (Comment) + uses: actions/upload-artifact@a8a3f3ad30e3422c9c7b888a15615d19a852ae32 + with: + name: learning-path-review + path: merge/learning-path-review/ diff --git a/.github/workflows/submit-learning-paths-staleness-check.yml b/.github/workflows/submit-learning-paths-staleness-check.yml new file mode 100644 index 00000000000..da3e649acd2 --- /dev/null +++ b/.github/workflows/submit-learning-paths-staleness-check.yml @@ -0,0 +1,76 @@ +name: 'Submit Learning Paths Staleness Check' + +on: + workflow_run: + workflows: ["Check Learning Path Links"] + types: + - completed + +permissions: + contents: write + issues: write + pull-requests: write + + +jobs: + submit-learning-paths-staleness-check: + if: github.event.workflow_run.conclusion == 'success' + runs-on: ubuntu-latest + permissions: + contents: write + issues: write + pull-requests: write + + steps: + - uses: actions/github-script@d7906e4ad0b1822421a7e6a35d5ca353c962f410 + id: check-user + with: + script: | + await github.rest.repos.checkCollaborator({ + owner: context.repo.owner, + repo: context.repo.repo, + username: context.payload.workflow_run.triggering_actor.login + }); + + - name: Checkout + uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab + with: + persist-credentials: true + + # Download the artifact from the workflow that kicked off this one. + # The default artifact download action doesn't support cross-workflow + # artifacts, so use a 3rd party one. + - name: 'Download linting results' + uses: dawidd6/action-download-artifact@246dbf436b23d7c49e21a7ab8204ca9ecd1fe615 + with: + workflow: ${{env.workflow_name}} + run_id: ${{github.event.workflow_run.id }} + name: learning-path-review + path: ./learning-path-review + + - name: Set Env Vars + run: | + modifiedFiles=$(cat ./learning-path-review/modifiedFiles) + manuallyReview=$(cat ./learning-path-review/manuallyReview) + echo "modifiedFiles=$modifiedFiles" >> $GITHUB_ENV + echo "manuallyReview=$manuallyReview" >> $GITHUB_ENV + + - uses: actions/github-script@v6 + name: Submit Comment + if: ${{ env.modifiedFiles != '' }} + env: + GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} + MODIFIED_FILES: ${{ env.modifiedFiles }} + MANUALLY_REVIEW: ${{ env.manuallyReview }} + with: + script: | + modifiedFiles = process.env.MODIFIED_FILES; + manuallyReview = process.env.MANUALLY_REVIEW; + comment_body = "### Learning Paths Links Check \n\nChanged files in the Learning Path:\n\n" + modifiedFiles.replaceAll(",", "\n") + "\n\n---------\n\n Files that should be manually reviewed:\n\n" + manuallyReview.replaceAll(",", "\n"); + github.rest.issues.createComment({ + issue_number: context.payload.workflow_run.pull_requests[0].number, + owner: context.repo.owner, + repo: context.repo.repo, + body: comment_body + }) + diff --git a/.github/workflows/submit-linter-suggestions.yml b/.github/workflows/submit-linter-suggestions.yml index 54f080d0938..b68a99aec33 100644 --- a/.github/workflows/submit-linter-suggestions.yml +++ b/.github/workflows/submit-linter-suggestions.yml @@ -2,7 +2,7 @@ name: 'Submit linter suggestions' on: workflow_run: - workflows: ["C# linting", "Add Markdown Feedback"] + workflows: ["C# linting", "Add Markdown Feedback", "Check Learning Path Links"] types: - completed @@ -45,6 +45,13 @@ jobs: run: | echo 'reporter_name=Add Markdown Feedback' >> $GITHUB_ENV echo 'workflow_name=add-markdown-feedback.yml' >> $GITHUB_ENV + + - name: Set Learning Path File Checks Env Vars + if: ${{ github.event.workflow_run.name == 'Check Learning Path Links' }} + run: | + echo 'reporter_name=Learning Path File Checks' >> $GITHUB_ENV + echo 'workflow_name=check-learning-path-links.yml' >> $GITHUB_ENV + # Download the artifact from the workflow that kicked off this one. # The default artifact download action doesn't support cross-workflow # artifacts, so use a 3rd party one. diff --git a/documentation/learningPath/architecture.md b/documentation/learningPath/architecture.md index 38476ca861c..e5ed2fc82b3 100644 --- a/documentation/learningPath/architecture.md +++ b/documentation/learningPath/architecture.md @@ -2,3 +2,10 @@ ### Was this documentation helpful? [Share feedback](https://www.research.net/r/DGDQWXH?src=documentation%2FlearningPath%2Farchitecture) # Architecture +This is a test of a deleted [file](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Tools/dotnet-monitor/OutputFormat.cs). + +This is a test of a shifted line [file](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Tools/dotnet-monitor/CollectionRules/Options/CollectionRuleTriggerOptions.cs#L24). + +This is a test of a removed line [file](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Tools/dotnet-monitor/CollectionRules/Options/CollectionRuleTriggerOptions.cs#L1). + +This is a test of an ambiguous line [file](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Tools/dotnet-monitor/CollectionRules/Options/CollectionRuleTriggerOptions.cs#L16). diff --git a/documentation/learningPath/collectionrules.md b/documentation/learningPath/collectionrules.md index 6ea6c9ce47e..dc7c0f8becb 100644 --- a/documentation/learningPath/collectionrules.md +++ b/documentation/learningPath/collectionrules.md @@ -32,49 +32,49 @@ graph LR ### Key Areas Of The Code -* Collection rules are registered [here](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Tools/dotnet-monitor/ServiceCollectionExtensions.cs#L100). When adding a new trigger or action, these types need to be added here to take effect. This section is also responsible for making sure options get configured and validated. -* Options for collection rules can be found [here](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Tools/dotnet-monitor/CollectionRules/Options/CollectionRuleOptions.cs). -* Rules are applied, removed, and restarted in response to configuration changes [here](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Tools/dotnet-monitor/CollectionRules/CollectionRuleService.cs). This is also responsible for generating a description of each collection rule's state for the `/collectionrules` API Endpoint. -* The pipeline responsible for the lifetime of a single executing collection rule can be found [here](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Tools/dotnet-monitor/CollectionRules/CollectionRulePipeline.cs#L55). -* To run collection rules, `dotnet monitor` must be in `Listen` mode - this is set via [DiagnosticPortOptions](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Microsoft.Diagnostics.Monitoring.Options/DiagnosticPortOptions.cs). +* Collection rules are registered [here](https://github.com/dotnet/dotnet-monitor/blob/main/src/Tools/dotnet-monitor/ServiceCollectionExtensions.cs#L100). When adding a new trigger or action, these types need to be added here to take effect. This section is also responsible for making sure options get configured and validated. +* Options for collection rules can be found [here](https://github.com/dotnet/dotnet-monitor/blob/main/src/Tools/dotnet-monitor/CollectionRules/Options/CollectionRuleOptions.cs). +* Rules are applied, removed, and restarted in response to configuration changes [here](https://github.com/dotnet/dotnet-monitor/blob/main/src/Tools/dotnet-monitor/CollectionRules/CollectionRuleService.cs). This is also responsible for generating a description of each collection rule's state for the `/collectionrules` API Endpoint. +* The pipeline responsible for the lifetime of a single executing collection rule can be found [here](https://github.com/dotnet/dotnet-monitor/blob/main/src/Tools/dotnet-monitor/CollectionRules/CollectionRulePipeline.cs#L54). +* To run collection rules, `dotnet monitor` must be in `Listen` mode - this is set via [DiagnosticPortOptions](https://github.com/dotnet/dotnet-monitor/blob/main/src/Microsoft.Diagnostics.Monitoring.Options/DiagnosticPortOptions.cs). * For each type of trigger, the [dotnet diagnostics repo](https://github.com/dotnet/diagnostics/blob/v6.0.351802/src/Microsoft.Diagnostics.Monitoring.EventPipe/Triggers/ITraceEventTrigger.cs#L29) is responsible for determining whether the triggering conditions have been satisfied. ### Triggers -A trigger will monitor for a specific condition in the target application and raise a notification when that condition has been observed. Options for triggers can be found [here](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Tools/dotnet-monitor/CollectionRules/Options/CollectionRuleTriggerOptions.cs); the type of `Settings` is determined by which trigger is being used (possible trigger types can be found [here](https://github.com/dotnet/dotnet-monitor/tree/v7.0.1/src/Tools/dotnet-monitor/CollectionRules/Options/Triggers)). The interface for all triggers can be found [here](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Tools/dotnet-monitor/CollectionRules/Triggers/ICollectionRuleTrigger.cs) - this allows `dotnet monitor` to start and stop triggers, regardless of the trigger's properties. The collection rule pipeline creates instances of triggers [here](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Tools/dotnet-monitor/CollectionRules/CollectionRulePipeline.cs#L100) before waiting for the trigger to [satisfy its conditions](https://github.com/dotnet/diagnostics/blob/v6.0.351802/src/Microsoft.Diagnostics.Monitoring.EventPipe/Triggers/Pipelines/TraceEventTriggerPipeline.cs#L107) - each trigger has its own set of criteria that determines when a trigger has been satisfied. +A trigger will monitor for a specific condition in the target application and raise a notification when that condition has been observed. Options for triggers can be found [here](https://github.com/dotnet/dotnet-monitor/blob/main/src/Tools/dotnet-monitor/CollectionRules/Options/CollectionRuleTriggerOptions.cs); the type of `Settings` is determined by which trigger is being used (possible trigger types can be found [here](https://github.com/dotnet/dotnet-monitor/tree/main/src/Tools/dotnet-monitor/CollectionRules/Options/Triggers)). The interface for all triggers can be found [here](https://github.com/dotnet/dotnet-monitor/blob/main/src/Tools/dotnet-monitor/CollectionRules/Triggers/ICollectionRuleTrigger.cs) - this allows `dotnet monitor` to start and stop triggers, regardless of the trigger's properties. The collection rule pipeline creates instances of triggers [here](https://github.com/dotnet/dotnet-monitor/blob/main/src/Tools/dotnet-monitor/CollectionRules/CollectionRulePipeline.cs#L99) before waiting for the trigger to [satisfy its conditions](https://github.com/dotnet/diagnostics/blob/v6.0.351802/src/Microsoft.Diagnostics.Monitoring.EventPipe/Triggers/Pipelines/TraceEventTriggerPipeline.cs#L107) - each trigger has its own set of criteria that determines when a trigger has been satisfied. ### Actions -Actions allow executing an operation or an external executable in response to a trigger condition being satisfied. Options for actions can be found [here](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Tools/dotnet-monitor/CollectionRules/Options/CollectionRuleActionOptions.cs); the type of `Settings` is determined by which action is being used (possible action types can be found [here](https://github.com/dotnet/dotnet-monitor/tree/v7.0.1/src/Tools/dotnet-monitor/CollectionRules/Options/Actions)). The interface for all actions can be found [here](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Tools/dotnet-monitor/CollectionRules/Actions/ICollectionRuleAction.cs) - this allows `dotnet monitor` to start an action, wait for it to complete, and get its output values regardless of the action's properties. The action list is [executed](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Tools/dotnet-monitor/CollectionRules/CollectionRulePipeline.cs#L150) once the triggering condition has been met (assuming the action list isn't throttled), with each action by default starting without waiting for prior actions to complete. +Actions allow executing an operation or an external executable in response to a trigger condition being satisfied. Options for actions can be found [here](https://github.com/dotnet/dotnet-monitor/blob/main/src/Tools/dotnet-monitor/CollectionRules/Options/CollectionRuleActionOptions.cs); the type of `Settings` is determined by which action is being used (possible action types can be found [here](https://github.com/dotnet/dotnet-monitor/tree/main/src/Tools/dotnet-monitor/CollectionRules/Options/Actions)). The interface for all actions can be found [here](https://github.com/dotnet/dotnet-monitor/blob/main/src/Tools/dotnet-monitor/CollectionRules/Actions/ICollectionRuleAction.cs) - this allows `dotnet monitor` to start an action, wait for it to complete, and get its output values regardless of the action's properties. The action list is [executed](https://github.com/dotnet/dotnet-monitor/blob/main/src/Tools/dotnet-monitor/CollectionRules/CollectionRulePipeline.cs#L149) once the triggering condition has been met (assuming the action list isn't throttled), with each action by default starting without waiting for prior actions to complete. ### Filters -Filters can optionally be applied to a collection rule to choose which processes can trigger the rule. This uses the same set of [options](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Microsoft.Diagnostics.Monitoring.Options/ProcessFilterOptions.cs#L47) as setting the default process for `dotnet-monitor`. When starting a collection rule, [these filters are used to check if the current process should have the collection rule applied to it](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Tools/dotnet-monitor/CollectionRules/CollectionRuleContainer.cs#L189); if so, the collection rule starts. +Filters can optionally be applied to a collection rule to choose which processes can trigger the rule. This uses the same set of [options](https://github.com/dotnet/dotnet-monitor/blob/main/src/Microsoft.Diagnostics.Monitoring.Options/ProcessFilterOptions.cs#L47) as setting the default process for `dotnet-monitor`. When starting a collection rule, [these filters are used to check if the current process should have the collection rule applied to it](https://github.com/dotnet/dotnet-monitor/blob/main/src/Tools/dotnet-monitor/CollectionRules/CollectionRuleContainer.cs#L189); if so, the collection rule starts. ### Limits -Limits can optionally be applied to a collection rule to constrain the lifetime of the rule and how often its actions can be run before being throttled. Options for limits can be found [here](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Tools/dotnet-monitor/CollectionRules/Options/CollectionRuleLimitsOptions.cs). When provided (or when using default values), limits are evaluated in the collection rule pipeline while running. `RuleDuration` is used to [create a token](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Tools/dotnet-monitor/CollectionRules/CollectionRulePipeline.cs#L80) that shuts down the pipeline. `ActionCountSlidingWindowDuration` does not rely on setting cancellation tokens; rather, the number of executions within the sliding window are checked on-demand [here](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Microsoft.Diagnostics.Monitoring.WebApi/CollectionRulePipelineState.cs#L212), and `ActionCount` is referenced to determine whether the rule needs to [terminate](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Microsoft.Diagnostics.Monitoring.WebApi/CollectionRulePipelineState.cs#L195) or [throttle](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Microsoft.Diagnostics.Monitoring.WebApi/CollectionRulePipelineState.cs#L235). +Limits can optionally be applied to a collection rule to constrain the lifetime of the rule and how often its actions can be run before being throttled. Options for limits can be found [here](https://github.com/dotnet/dotnet-monitor/blob/main/src/Tools/dotnet-monitor/CollectionRules/Options/CollectionRuleLimitsOptions.cs). When provided (or when using default values), limits are evaluated in the collection rule pipeline while running. `RuleDuration` is used to [create a token](https://github.com/dotnet/dotnet-monitor/blob/main/src/Tools/dotnet-monitor/CollectionRules/CollectionRulePipeline.cs#L79) that shuts down the pipeline. `ActionCountSlidingWindowDuration` does not rely on setting cancellation tokens; rather, the number of executions within the sliding window are checked on-demand [here](https://github.com/dotnet/dotnet-monitor/blob/main/src/Microsoft.Diagnostics.Monitoring.WebApi/CollectionRulePipelineState.cs#L212), and `ActionCount` is referenced to determine whether the rule needs to [terminate](https://github.com/dotnet/dotnet-monitor/blob/main/src/Microsoft.Diagnostics.Monitoring.WebApi/CollectionRulePipelineState.cs#L195) or [throttle](https://github.com/dotnet/dotnet-monitor/blob/main/src/Microsoft.Diagnostics.Monitoring.WebApi/CollectionRulePipelineState.cs#L235). ## Miscellaneous ### Trigger Shortcuts -Trigger Shortcuts provide improved defaults, range validation, and a simpler syntax for [several commonly used `EventCounter` triggers](https://github.com/dotnet/dotnet-monitor/tree/v7.0.1/src/Tools/dotnet-monitor/CollectionRules/Options/Triggers/EventCounterShortcuts). These shortcuts provide the same functionality as using the standard `EventCounter` syntax, but have fewer available options (since there is no need to specify the `ProviderName` or the `CounterName`) - as a result, shortcuts do not inherit from `EventCounterOptions`, but rather [IEventCounterShortcuts](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Tools/dotnet-monitor/CollectionRules/Options/Triggers/EventCounterShortcuts/IEventCounterShortcuts.cs). Each type of shortcut is registered independently [here](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Tools/dotnet-monitor/ServiceCollectionExtensions.cs#L117). After binding with configuration and undergoing validation, shortcuts are then converted to be treated as `EventCounter` triggers [here](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Tools/dotnet-monitor/CollectionRules/Triggers/EventCounterTriggerFactory.cs), using their respective defaults instead of the generic ones. +Trigger Shortcuts provide improved defaults, range validation, and a simpler syntax for [several commonly used `EventCounter` triggers](https://github.com/dotnet/dotnet-monitor/tree/main/src/Tools/dotnet-monitor/CollectionRules/Options/Triggers/EventCounterShortcuts). These shortcuts provide the same functionality as using the standard `EventCounter` syntax, but have fewer available options (since there is no need to specify the `ProviderName` or the `CounterName`) - as a result, shortcuts do not inherit from `EventCounterOptions`, but rather [IEventCounterShortcuts](https://github.com/dotnet/dotnet-monitor/blob/main/src/Tools/dotnet-monitor/CollectionRules/Options/Triggers/EventCounterShortcuts/IEventCounterShortcuts.cs). Each type of shortcut is registered independently [here](https://github.com/dotnet/dotnet-monitor/blob/main/src/Tools/dotnet-monitor/ServiceCollectionExtensions.cs#L117). After binding with configuration and undergoing validation, shortcuts are then converted to be treated as `EventCounter` triggers [here](https://github.com/dotnet/dotnet-monitor/blob/main/src/Tools/dotnet-monitor/CollectionRules/Triggers/EventCounterTriggerFactory.cs), using their respective defaults instead of the generic ones. ### Templates -Templates allow users to design reusable collection rule components by associating a name with a piece of configuration. Options for templates can be found [here](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Tools/dotnet-monitor/CollectionRules/Options/TemplateOptions.cs). Before collection rules undergo validation, `dotnet monitor` checks to see if any of the rule's components in configuration [list the name of a template](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Tools/dotnet-monitor/CollectionRules/Configuration/CollectionRulePostConfigureNamedOptions.cs) - if so, the collection rule's options are populated from the correspondingly named template. Note that templates undergo the same binding process for triggers/actions as collection rules; however, since templates are treated as separate parts of configuration, this binding instead happens [here](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Tools/dotnet-monitor/CollectionRules/Configuration/TemplatesConfigureNamedOptions.cs). +Templates allow users to design reusable collection rule components by associating a name with a piece of configuration. Options for templates can be found [here](https://github.com/dotnet/dotnet-monitor/blob/main/src/Tools/dotnet-monitor/CollectionRules/Options/TemplateOptions.cs). Before collection rules undergo validation, `dotnet monitor` checks to see if any of the rule's components in configuration [list the name of a template](https://github.com/dotnet/dotnet-monitor/blob/main/src/Tools/dotnet-monitor/CollectionRules/Configuration/CollectionRulePostConfigureNamedOptions.cs) - if so, the collection rule's options are populated from the correspondingly named template. Note that templates undergo the same binding process for triggers/actions as collection rules; however, since templates are treated as separate parts of configuration, this binding instead happens [here](https://github.com/dotnet/dotnet-monitor/blob/main/src/Tools/dotnet-monitor/CollectionRules/Configuration/TemplatesConfigureNamedOptions.cs). ### Collection Rule Defaults -Defaults can be used to limit the verbosity of configuration, allowing frequently used values for collection rules to be assigned as defaults. Options for collection rule defaults can be found [here](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Tools/dotnet-monitor/CollectionRules/Options/CollectionRuleDefaultsOptions.cs). These defaults are merged with the user's provided configuration [here](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Tools/dotnet-monitor/CollectionRules/Options/DefaultCollectionRulePostConfigureOptions.cs) - any properties that the user hasn't set (that have corresponding default values) will be updated at this point to use the default values. This step occurs prior to `dotnet monitor` attempting to use its built-in defaults, which allows user defaults to take precedence. +Defaults can be used to limit the verbosity of configuration, allowing frequently used values for collection rules to be assigned as defaults. Options for collection rule defaults can be found [here](https://github.com/dotnet/dotnet-monitor/blob/main/src/Tools/dotnet-monitor/CollectionRules/Options/CollectionRuleDefaultsOptions.cs). These defaults are merged with the user's provided configuration [here](https://github.com/dotnet/dotnet-monitor/blob/main/src/Tools/dotnet-monitor/CollectionRules/Options/DefaultCollectionRulePostConfigureOptions.cs) - any properties that the user hasn't set (that have corresponding default values) will be updated at this point to use the default values. This step occurs prior to `dotnet monitor` attempting to use its built-in defaults, which allows user defaults to take precedence. ### Collection Rule API Endpoint -The Collection Rule API Endpoint allows users to get information about the state of their collection rules, providing general information [here](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Microsoft.Diagnostics.Monitoring.WebApi/Controllers/DiagController.cs#L532) and more specific information about a particular rule [here](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Microsoft.Diagnostics.Monitoring.WebApi/Controllers/DiagController.cs#L557). **This API is solely for viewing the current state of rules, not altering state**. +The Collection Rule API Endpoint allows users to get information about the state of their collection rules, providing general information [here](https://github.com/dotnet/dotnet-monitor/blob/main/src/Microsoft.Diagnostics.Monitoring.WebApi/Controllers/DiagController.cs#L532) and more specific information about a particular rule [here](https://github.com/dotnet/dotnet-monitor/blob/main/src/Microsoft.Diagnostics.Monitoring.WebApi/Controllers/DiagController.cs#L557). **This API is solely for viewing the current state of rules, not altering state**. -Each collection rule pipeline has a [state holder](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/src/Microsoft.Diagnostics.Monitoring.WebApi/CollectionRulePipelineState.cs) that keeps track of the rule's execution. By keeping track of the pipeline's state in real-time, this state doesn't need to be calculated in response to a user hitting the `/collectionrules` endpoint. However, other user-facing information, such as countdowns, are calculated on-demand - these values are solely for display purposes and not used by `dotnet-monitor` when determining when to change state (see [Limits](#limits) for more information). +Each collection rule pipeline has a [state holder](https://github.com/dotnet/dotnet-monitor/blob/main/src/Microsoft.Diagnostics.Monitoring.WebApi/CollectionRulePipelineState.cs) that keeps track of the rule's execution. By keeping track of the pipeline's state in real-time, this state doesn't need to be calculated in response to a user hitting the `/collectionrules` endpoint. However, other user-facing information, such as countdowns, are calculated on-demand - these values are solely for display purposes and not used by `dotnet-monitor` when determining when to change state (see [Limits](#limits) for more information). ## Keeping Documentation Up-To-Date -When making changes to collection rules that require updates to configuration, these changes should be added [here](https://github.com/dotnet/dotnet-monitor/blob/v7.0.1/documentation/configuration.md#collection-rule-configuration). Additional information on collection rules and examples can be provided [here](https://github.com/dotnet/dotnet-monitor/tree/v7.0.1/documentation/collectionrules). +When making changes to collection rules that require updates to configuration, these changes should be added [here](https://github.com/dotnet/dotnet-monitor/blob/main/documentation/configuration.md#collection-rule-configuration). Additional information on collection rules and examples can be provided [here](https://github.com/dotnet/dotnet-monitor/tree/main/documentation/collectionrules). diff --git a/src/Tools/dotnet-monitor/CollectionRules/Options/CollectionRuleTriggerOptions.cs b/src/Tools/dotnet-monitor/CollectionRules/Options/CollectionRuleTriggerOptions.cs index 1ea171a3219..9c3ea8532f0 100644 --- a/src/Tools/dotnet-monitor/CollectionRules/Options/CollectionRuleTriggerOptions.cs +++ b/src/Tools/dotnet-monitor/CollectionRules/Options/CollectionRuleTriggerOptions.cs @@ -1,6 +1,14 @@ // Licensed to the .NET Foundation under one or more agreements. // The .NET Foundation licenses this file to you under the MIT license. +// Simple test 24. +// This should not cause a new comment. +// This should cause a new comment. +// Another new comment 3. +// Yet another comment 2. +// Another one 7. +// ...And another one. + using Microsoft.Diagnostics.Monitoring.WebApi; using System.ComponentModel.DataAnnotations; using System.Diagnostics;