Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Correlator race condition when using matrices #73

Open
ebickle opened this issue Apr 19, 2024 · 0 comments
Open

Correlator race condition when using matrices #73

ebickle opened this issue Apr 19, 2024 · 0 comments

Comments

@ebickle
Copy link

ebickle commented Apr 19, 2024

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:

jobs:
  dependency-submission-maven:
    name: Dependency Submission - Maven
    runs-on: ubuntu-latest

    permissions:
      contents: write

    strategy: 
      matrix:
        directory: 
          - project-one
          - project-two

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Set up JDK
        uses: actions/setup-java@v4
        with:
          java-version: 11
          distribution: temurin

      - name: Submit Dependency Snapshot
        uses: advanced-security/maven-dependency-submission-action@v4
        with:
          directory: ${{ matrix.directory }}

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:

   "job": {
        "correlator": "dependency-submission-maven",
        "id": "8748150998"
    },
    "detector": {
        "name": "maven-dependency-submission-action",
        "url": "https://github.com/advanced-security/maven-dependency-submission-action",
        "version": "4.0.2"
    }

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant