-
Notifications
You must be signed in to change notification settings - Fork 1
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
[PF-2987] Add dependabot for 3rd party library upgrades, remove lockfiles and spotbugs #115
Conversation
@@ -1,140 +0,0 @@ | |||
# This is a Gradle generated file for dependency locking. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not that I"m complaining but why the removal of hte .lockfiles?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We've been removing lockfiles in all of our repos to make dependency upgrades easier.
timezone: "America/New_York" | ||
target-branch: "develop" | ||
reviewers: | ||
- "@DataBiosphere/platform-foundation-codeowners" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just double checking that these reviewers are the group we want for this (out of ignorance on my part 😬)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we talked about this today at the "round table" meeting. It might not be the perfect group for reviews, but we don't wish to maintain a second group.
I don't understand why this isn't kicking off any tests (given the source code changes). |
It looks like tests are not triggered on commits. I am putting this PR into draft until we get unit tests running. |
import org.apache.commons.lang3.ClassUtils; | ||
import org.apache.commons.lang3.StringUtils; | ||
import org.apache.commons.lang3.tuple.ImmutablePair; | ||
import org.apache.commons.lang3.tuple.Pair; | ||
import org.slf4j.Logger; | ||
import org.slf4j.LoggerFactory; | ||
import org.springframework.lang.Nullable; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
javax.annotation.Nullable
was coming from spotbugs (https://www.javadoc.io/doc/com.google.code.findbugs/jsr305/latest/javax/annotation/Nullable.html).
There seem to be lots of options for @nullable, so I went with a package that was already available with our current dependencies. We do use this package in some of our other repos. https://github.com/search?q=org%3ADataBiosphere%20org.springframework.lang.Nullable&type=code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think a better fix would be to use jakarta.annotation.Nullable
, as it doesn't require a framework dependency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It didn't seem that was available with our current dependencies/framework, but perhaps IntelliJ was lying to me?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it might need an additional dependency like https://mvnrepository.com/artifact/jakarta.annotation/jakarta.annotation-api
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I started looking into adding that, but then punted since we use org.springframework.lang.Nullable
in some of our other repos.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It sounds like we're not sure if we want to remove spotbugs yet since sonarqube isnt in this repo. Would it be worthwhile to separate the dependabot changes from the spotbugs stuff to get that in?
The changes look fine overall.
This, @jsotobroad . I agree that I could pull out the spotbugs removal, but first I'm going to reach out to infosec folks and see if we can just get sonarqube running on this repo. |
@jsotobroad , @TomConner is OK with us going ahead and removing spotbugs. So this PR is now ready for review. https://broadinstitute.slack.com/archives/CADU7L0SZ/p1709132894654009 |
|
@@ -50,7 +48,7 @@ jobs: | |||
cache: 'gradle' | |||
- name: Run tests | |||
run: ./gradlew test | |||
|
|||
# TODO: Work with AppSec to get Sonar scans setup for this repo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👋
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for taking this on! I have some Stairway work in flight and will be really happy to see the lockfiles go away :)
Same configuration as in terra-common-library.
Also removes lockfiles and spotbugs, similar to what we have done in our other libraries (for example, DataBiosphere/terra-common-lib#148 and DataBiosphere/terra-common-lib#147).