We have many repositories that contain multiple maven "aggregator projects" in a single repository. In other words, there are multiple pom.xml files where two or more are not a sub-module of another.
This means that we need to run maven-dependency-submission-action multiple times for a single commit. One way we do this by using a matrix in a workflow, a bit like this:
However, this causes a race condition where the last dependency submission "wins" and overwrites the manifest of another. We can see this in the job and detector fields of the submission:
The @github/dependency-submission-toolkit dependency defaults to setting job.correlator to the job id, which is constant when a using matrix or other technique that submits multiple snapshot in the same workflow. This ends up creating a significant challenge whenever there are multiple "root" projects (of any type) in a repository, a pattern very common with monorepos.
A possible solution would be to add a correlator input field to the action.yml file. When set, the value of inputs.correlator would be used instead of the default. This design mimics the category field of the CodeQL actions but is somewhat non-intuitive.
Alternate solutions are more difficult to implement and have more tradeoffs, but could include:
Dynamically generate a correlator value based on the relative path to the directory input parameter. Using the directory structure example example above, correlator values of dependency-submission-maven-project-one and depenendecy-submission-maven-project-two would be used. This could potentially be a minor breaking change depending on how the Dependency Submission API retains previous submissions and would require some special path manipulation to ensure that unsupported characters are mapped to values supported by the correlator field (e.g. / to -).
Have a new major version of maven-dependency-submission-action scan for all pom.xml files at the level of directory and all child directories, generate reactor.xml files for each, generate dependencies for each pom, then submit all the results together in a single manifest. While the most intuitive and user-friendly, this would be a massive change and likely require coordination across the other similar dependency submission actions to ensure they all work equivalently.
I'm leaning towards the correlator input field option due to it's simplicity and alignment with CodeQL, but wanted to check in first. I'm not quite sure what the long term direction of this action is, particularly given the GitHub roadmap item relating to Maven scanning.
We have many repositories that contain multiple maven "aggregator projects" in a single repository. In other words, there are multiple
pom.xml
files where two or more are not a sub-module of another.This means that we need to run
maven-dependency-submission-action
multiple times for a single commit. One way we do this by using a matrix in a workflow, a bit like this:However, this causes a race condition where the last dependency submission "wins" and overwrites the manifest of another. We can see this in the
job
anddetector
fields of the submission:The
@github/dependency-submission-toolkit
dependency defaults to settingjob.correlator
to the job id, which is constant when a using matrix or other technique that submits multiple snapshot in the same workflow. This ends up creating a significant challenge whenever there are multiple "root" projects (of any type) in a repository, a pattern very common with monorepos.A possible solution would be to add a
correlator
input field to theaction.yml
file. When set, the value ofinputs.correlator
would be used instead of the default. This design mimics thecategory
field of the CodeQL actions but is somewhat non-intuitive.Alternate solutions are more difficult to implement and have more tradeoffs, but could include:
Dynamically generate a
correlator
value based on the relative path to thedirectory
input parameter. Using the directory structure example example above, correlator values ofdependency-submission-maven-project-one
anddepenendecy-submission-maven-project-two
would be used. This could potentially be a minor breaking change depending on how the Dependency Submission API retains previous submissions and would require some special path manipulation to ensure that unsupported characters are mapped to values supported by the correlator field (e.g./
to-
).Have a new major version of
maven-dependency-submission-action
scan for all pom.xml files at the level ofdirectory
and all child directories, generate reactor.xml files for each, generate dependencies for each pom, then submit all the results together in a single manifest. While the most intuitive and user-friendly, this would be a massive change and likely require coordination across the other similar dependency submission actions to ensure they all work equivalently.I'm leaning towards the
correlator
input field option due to it's simplicity and alignment with CodeQL, but wanted to check in first. I'm not quite sure what the long term direction of this action is, particularly given the GitHub roadmap item relating to Maven scanning.