From 8a684e9cbd5c33c6ed606aa02ffb6a58b7556ef1 Mon Sep 17 00:00:00 2001 From: Daz DeBoer Date: Fri, 18 Aug 2023 15:48:25 -0600 Subject: [PATCH] Update README.md --- README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index ac34a0a..27382a4 100644 --- a/README.md +++ b/README.md @@ -564,10 +564,10 @@ There are a number of techniques you can employ to limit the scope of the genera - [For a Gradle execution, filter which Gradle projects and configurations will contribute dependencies](#filtering-which-gradle-configurations-contribute-to-the-dependency-graph) - [Use a separate workflow that only resolves the required dependencies]() -[!NOTE] -Ideally, all dependencies involved in building and testing a project will be extracted and reported in a dependency graph. -These dependencies would be assigned to different scopes (eg development, runtime, testing) and the GitHub UI would make it easy to opt-in to security alerts for different dependency scopes. -However, this functionality does not yet exist. +> [!NOTE] +> Ideally, all dependencies involved in building and testing a project will be extracted and reported in a dependency graph. +> These dependencies would be assigned to different scopes (eg development, runtime, testing) and the GitHub UI would make it easy to opt-in to security alerts for different dependency scopes. +> However, this functionality does not yet exist. ### Choosing which Gradle invocations will generate a dependency graph