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

Added (basic) support for build.gradle files #707

Closed
wants to merge 3 commits into from
Closed

Added (basic) support for build.gradle files #707

wants to merge 3 commits into from

Conversation

bolshoytoster
Copy link

Added a file in syft/pkg/cataloger/java/, gradle_parser.go, this parses build.gradle files:

  • First, it finds the 'dependency' parts while also parsing and inserting any defined variables.
  • Next, it splits the sections into individual dependencies.
  • Finally, it splits the string by colons, taking the second part as the Name and the third as the Version.

I tried to keep it as close to other code in the repository, particularly syft/pkg/cataloger/apkdb/parse_apk_db.go

I've added a NewJavaGradleCataloger function to syft/pkg/cataloger/cataloger.go.

I changed "java-cataloger" to "java-archive-cataloger".

I'm not sure about tests, I probably could use some help with writing them.

I've also fixed two typos.

Added a file in syft/pkg/cataloger/java/, gradle_parser.go, this parses build.gradle files:
- First, it finds the 'dependency' parts while also parsing and inserting any `def`ined variables.
- Next, it splits the sections into individual dependencies.
- Finally, it splits the string by colons, taking the second part as the `Name` and the third as the `Version`.

I tried to keep it as close to other code in the repository, particularly syft/pkg/cataloger/apkdb/parse_apk_db.go

I've added a `NewJavaGradleCataloger` function to syft/pkg/cataloger/cataloger.go.

I changed `"java-cataloger"` to `"java-archive-cataloger"`.

I'm not sure about tests, I probably could use some help with them.

I've also fixed two typos.
// integrity check
var _ common.ParserFn = parseJaveGradle

func parseJaveGradle(_ string, reader io.Reader) ([]pkg.Package, []artifact.Relationship, error) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you add tests around this parser function?

variables := make(map[string][]byte)

// get each 'dependency {}' section
onDependency := func(data []byte, atEOF bool) (advance int, token []byte, err error) {
Copy link
Contributor

@wagoodman wagoodman Jan 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see why this particular parser function is complex, mostly since the build.gradle file is groovy syntax and short of a groovy AST parser there isn't a straightforward way to extract the information in question. The split functions are pretty dense from a reading and understanding point of view, and I'm hesitant to change them without a body of tests around the split functions themselves.

Assuming there isn't any shared state in the stack that is leveraged, can you extract out all of the split functions and put them individually under test?

@wagoodman
Copy link
Contributor

we require that all commits on a PR are signed off as well as signed --can you update your commits? Shout out if you have any questions!

@spiffcs
Copy link
Contributor

spiffcs commented Jan 19, 2022

hey @bolshoytoster I just wanted to follow up with the comment here:
#707 (comment)

Are you able to sign the commits and resolve the conflicts? We would love to get this aligned with main so we can accept your contribution

@henrysachs
Copy link
Contributor

hi any idea why this has been closed? really interested in that feature. Maybe i can pick up the pr?

@kzantow
Copy link
Contributor

kzantow commented Dec 13, 2022

@henrysachs -- it looks like the author closed it, it's unclear why. I'm completely speculating but perhaps the author did not have time to finish this PR by adding tests and such. Being able to catalog Gradle files does sound like something we'd like to have!

@henrysachs
Copy link
Contributor

Hey,

Sounds reasonable. I would like to pick this up. Can you point me to some tests for other cataloggers where I would be able to find the right path for implementing them?

@kzantow
Copy link
Contributor

kzantow commented Dec 13, 2022

@henrysachs a couple points here:

@henrysachs
Copy link
Contributor

@bolshoytoster if you're reading this I would be happy to chat.

But I would probably only take the above described algorithm and not the code itself as you said catalogers changed quite a bit.

@bolshoytoster
Copy link
Author

@henrysachs

hi any idea why this has been closed?

I had no clue how to implement tests, and I also definetely needed to simplify and clean up the code. (It was definetely made more complicated by supporting variables.

Maybe i can pick up the pr?

If you want to, but you'll have to either clean up my code or write a more simplified version.

@henrysachs
Copy link
Contributor

I just learned parsing gradle files isn't that easy but that will be a fun activity. So give me some time :D

@kzantow
Copy link
Contributor

kzantow commented Dec 13, 2022

@henrysachs @bolshoytoster -- it looks like you might want to split this into a couple commits, one of which might use --author or use co-authoring to properly attribute any changes to @bolshoytoster -- I'll let the two of you figure out proper attribution here, but I'm also happy to help get this to the finish line!!

@henrysachs
Copy link
Contributor

as soon as i have something to show and discuss I will ping both of you guys. I think co-authoring sounds good to me, but lets discuss this as soon as the first pr from my fork is ready. :)

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

Successfully merging this pull request may close these issues.

None yet

5 participants