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

Possible to submit multiple, independent projects? #84

Closed
mkurz opened this issue Feb 28, 2023 · 10 comments · Fixed by #93 or #96
Closed

Possible to submit multiple, independent projects? #84

mkurz opened this issue Feb 28, 2023 · 10 comments · Fixed by #93 or #96
Assignees

Comments

@mkurz
Copy link
Contributor

mkurz commented Feb 28, 2023

Sorry for my ignorance in case that is possible anyway and I just couldn't figure it out or was misconfiguring things or was discussed already.

Let's say I have a repository with two independent projects project_a/build.sbt and project_b/build.sbt.
Can I submit both of those build.sbt files to GitHub so they show up independent in the /network/dependencies view?
I tried that with the Play Framework were we have a build.sbt and a documentation/build.sbt, but in the GitHub UI only the build.sbt shows up.
The workflow: https://github.com/playframework/playframework/blob/3c21f31f28c27ad00c9495096fa60e25a4b67050/.github/workflows/dependency-graph.yml#L24-L27

I think this has to be possible somehow because in our Dependency UI it shows all our (multiple) yml workflow files already.

@adpi2
Copy link
Member

adpi2 commented Feb 28, 2023

Thanks for opening this issue. It should indeed be possible to submit multiple independent projects but currently it is not.

The problem is that currently all manifests are declared as coming from a single build file build.sbt:

// TODO: find exact build file for this project
val file = githubapi.FileInfo("build.sbt")

I think we can fix this by comparing the sbt baseDirectory with the GITHUB_WORKSPACE from Github default env variables.

@mkurz
Copy link
Contributor Author

mkurz commented Mar 1, 2023

@adpi2 Thanks! Would be nice to have this working 😉

@mkurz
Copy link
Contributor Author

mkurz commented Mar 24, 2023

Thanks for fixing. However how does that actually work now?
Do I need to run a separate step for each project? E.g.

...
steps:
  - uses: actions/checkout@v3
  - uses: scalacenter/sbt-dependency-submission@v2
    with:
      working-directory: ./my-scala-project-one
  - uses: scalacenter/sbt-dependency-submission@v2
    with:
      working-directory: ./my-scala-project-two

Or does the action detect all build.sbt files automatically?

@adpi2
Copy link
Member

adpi2 commented Mar 24, 2023

Thanks for fixing. However how does that actually work now?
Do I need to run a separate step for each project? E.g.

Yes you still need to run a separate step for each project.

The fix is released in 2.2.1. @mkurz Could you test that it works as expected?

@adpi2
Copy link
Member

adpi2 commented Mar 24, 2023

It seems that Github only takes into account the latest snapshot of a job. See for instance, this job submitted three snaphsots but only one is displayed in the Dependency Graph view

@adpi2 adpi2 reopened this Mar 24, 2023
@mkurz
Copy link
Contributor Author

mkurz commented Mar 24, 2023

@adpi2 Exactly, see my comment playframework/play-mailer#250 (comment)

@adpi2
Copy link
Member

adpi2 commented Mar 24, 2023

@mkurz, thanks for the comment. Being able to send the manifests of several build in a single snapshot would require quite some changes in the architecture of the action. I could try it but I think there is a simpler fix.

Currently we use the pair GITHUB_RUN_ID and GITHUB_JOB as identifier of a snapshot. In your job there are possibly both the same and that would be why the snapshots get overwritten.

@adpi2
Copy link
Member

adpi2 commented Mar 24, 2023

Found some interesting documentation about that problem:

Correlator provides a key that is used to group snapshots submitted over time. Only the "latest" submitted snapshot for a given combination of job.correlator and detector.name will be considered when calculating a repository's current dependencies. Correlator should be as unique as it takes to distinguish all detection runs for a given "wave" of CI workflow you run. If you're using GitHub Actions, a good default value for this could be the environment variables GITHUB_WORKFLOW and GITHUB_JOB concatenated together. If you're using a build matrix, then you'll also need to add additional key(s) to distinguish between each submission inside a matrix variation.

@adpi2 adpi2 closed this as completed in #96 Mar 24, 2023
@adpi2
Copy link
Member

adpi2 commented Mar 24, 2023

@mkurz If you can try again to run your dependency submission that would be very helpful

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