Closed androa closed 1 year ago
To be clear, by SBOM you're referring to the generated dependency graph file JSON file?
Note that a workflow can generate multiple dependency graph files for submission, and they don't necessarily arise from the gradle-build-action
step.
Consider this workflow job: https://github.com/gradle/gradle-build-action/blob/main/.github/workflows/integ-test-dependency-graph.yml#L70-L98.
dependency-graph-reports/job-correlator.json
dependency-graph-reports/job-correlator1.json
So the options are:
${{ steps.setup-gradle.outputs.dependency-graphs-dir }}
${{ steps.run-assemble.outputs.dependency-graph }}
and ${{ steps.run-build.outputs.dependency-graph }}
Option 1. is by far the simplest: would that meet you requirements, since you can just capture the directory contents as a whole?
Option 2. would be more involved, since these don't execute with gradle-build-action
. But there are mechanisms to write step output directly.
That's correct, it's the JSON file I need.
The next action that requires the SBOM only supports a single file - so at some point I need to boil it down to just one file.
Getting the dependency-graphs-dir
would make it slightly more robust than just using the default path.
But the filename of the file itself would behave quite flaky when it is derived from the name of the workflow + job name. It would be more ideal with option 2.
In my case it would probably work as I everything in the gradle-build-action
.
You can see my current workflow.
In my case it would probably work as I everything in the gradle-build-action.
Right, but I'm not going to special-case the execution spawned by gradle-build-action
over the execution in a subsequent step.
In fact, a future release of the action will likely be named setup-gradle
and will deprecate the arguments
parameter. Instead, you'll use it like any other setup-X
action: to configure the tool for use in later steps.
Yeah, that makes sense. I think option 2 you outlined would be the best. An alternative that would alleviate some of the fragility is using the GITHUB_JOB_CORRELATOR
variable (or the intent of it through a more explicit API).
My need is really a predictable way of constructing the full path to a specific SBOM-file created by a specific Gradle execution.
Yeah, that makes sense. I think option 2 you outlined would be the best. An alternative that would alleviate some of the fragility is using the GITHUB_JOB_CORRELATOR variable (or the intent of it through a more explicit API).
Again, this was complicated by the need to handle Steps that aren't under the control of the gradle-build-action
. All of the functionality is encoded in this init-script, which impacts all Gradle invocations in the Job.
You can see that in the single-execution case, you can get the output file path as $DEPENDENCY_GRAPH_REPORT_DIR/$GITHUB_JOB_CORRELATOR
. Any subsequent Gradle execution will append a digit to the correlator to ensure uniqueness.
If you want to try creating the step output (option 2 above), you can fork this action and add a line to the init script. Something like:
def gitHubOutputFile = new File(System.getenv("GITHUB_OUTPUT"))
def dependencyGraphFile = new File(reportsDir, "${jobCorrelator}.json")
gitHubOutputFile << "dependency-graph-file=dependencyGraphFile.absolutePath
Finally back from vacation, just tested the output you added in 2.7.0. Worked like a charm! Thank you! 🙇 🚀
Just tried the new dependency-graph feature and it works really well, good job!
As a part of our deployment we also provide the SBOM-file for internal tracking. Currently I'm getting that through the path to the file in the current workspace, but it would be much more robust if it could be an output if the Action so I can use something along the lines of
${{ steps.build-with-sbom.outputs.sbom }}