tianzixuan/gradle-build-action
1
0
Fork 0
mirror of https://github.com/gradle/gradle-build-action.git synced 2024-12-26 01:36:19 +08:00
Code Issues Packages Projects Releases Wiki Activity

Clarify docs for dedicated workflow

Browse Source 
Fixes #976
This commit is contained in:
daz 2023-12-11 19:48:32 -07:00
parent 0280eb7de5
commit 4f0075d967
No known key found for this signature in database
1 changed files with 8 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
README.md
View File

@ -684,7 +684,7 @@ jobs:
uses: gradle/gradle-build-action@v2 uses: gradle/gradle-build-action@v2
with: with:
dependency-graph: generate-and-submit dependency-graph: generate-and-submit
- name: Run a build, generating the dependency graph from 'runtimeClasspath' configurations - name: Run a build, generating the dependency graph from any resolved 'runtimeClasspath' configurations
run: ./gradlew build run: ./gradlew build
env: env:
DEPENDENCY_GRAPH_INCLUDE_PROJECTS: "^:(?!buildSrc).*" DEPENDENCY_GRAPH_INCLUDE_PROJECTS: "^:(?!buildSrc).*"
@ -693,10 +693,10 @@ jobs:
### Use a dedicated workflow for dependency graph generation ### Use a dedicated workflow for dependency graph generation
Instead of generating a dependency graph from your existing CI workflow, it's possible to create a separate dedicated workflow (or Job) that is solely intended for generating a dependency graph. Instead of generating a dependency graph from your existing CI workflow, it's possible to create a separate dedicated workflow (or Job) that is intended for generating a dependency graph.
Such a workflow will still need to execute Gradle, but can do so in a way that is targeted at resolving exactly the dependencies required. Such a workflow will still need to execute Gradle, but can do so in a way that is targeted at resolving the specific dependencies required.
For example, the following workflow will report only those dependencies that are part of the `runtimeClasspath` or the `my-app` project. For example, the following workflow will report those dependencies that are resolved in order to build the `distributionZip` for the `my-app` project. Test dependencies and other dependencies not required by the `distributionZip` will not be included.
```yaml ```yaml
jobs: jobs:
@ -708,11 +708,12 @@ jobs:
uses: gradle/gradle-build-action@v2 uses: gradle/gradle-build-action@v2
with: with:
dependency-graph: generate-and-submit dependency-graph: generate-and-submit
- name: Extract the 'runtimeClasspath' dependencies for 'my-app' - name: Build the distribution Zip for `my-app`
run: ./gradlew :my-app:dependencies --configuration runtimeClasspath run: ./gradlew :my-app:distributionZip
``` ```
Note that the above example will also include `buildSrc` dependencies, since these are resolved as part of running the `dependencies` task. Note that the above example will also include any `buildSrc` dependencies, dependencies resolved when configuring your Gradle build or dependencies resolved while applying plugin. All of these dependencies are resolved in the process of running the `distributionZip` task, and thus will form part of the generated dependency graph.
If this isn't desirable, you will still need to use the filtering mechanism described above. If this isn't desirable, you will still need to use the filtering mechanism described above.
## Dependency Graphs for pull request workflows ## Dependency Graphs for pull request workflows