Nancy uses Nexus IQ Server, the journey

[DarthHater]

This is a quick lil ditty to get Nancy to work with Nexus IQ Server

This pull request makes the following changes:

• Adds iq.go that handles communication with Nexus IQ
• Adds cyclonedx package that will turn a []packageurl.PackageURL of purls into a minimal SBOM string
• Adds command line config options that shouldn't interfere with current OSS Index usage such that you call ./nancy iq -a application

Successful output looks like:

(base) 685 me:nancy (NancyWithIQ *)$ go list -m all | ./nancy iq -application testapp
2020/01/02 12:09:12 Nancy version: development
..........
Wonderbar! No policy violations reported for this audit!
Report URL:  http://localhost:8070/ui/links/application/testapp/report/7a9655ecf31c40cb89149378b64e439a

Draft PR for now so we people can laugh at my implementation with less shame. I'll add README results after we sort what I did technically.

cc @bhamail / @zendern / @ken-duck / @ajbrown / @fitzoh

[zendern]

Why would the default be develop?? Im going to guess 99% of the time this will be running on CI so shouldn't it be build. Keep in mind i have no real idea what this stages mean in IQ (only briefly read some of the docs :) ) so I'll defer to you of course.

[DarthHater]

You have build > develop > release-stage > release. I went with develop as a default as Nancy can be used by developers locally pretty easy. We could set it to build for sure, but it kinda depends on how you setup your policy TBH with Nexus IQ. I originally had it as build ftr. I can go either way!

[zendern]

Cool cool.... that makes sense then.

#scopeCreepAndMaybeNotWorthIt
But would it make sense to detect if on CI (looking for TRAVIS, CIRCLECI, CI, etc etc) environment variables and if one of those is set you change the stage automagically to build/release-stage?? Maybe that is still back into the "how you setup your policy in Nexus IQ" again and it doesn't matter. ¯_(ツ)_/¯

[DarthHater]

I LIKE THAT. We'd still need to allow someone to override it, though, because people use Travis, CircleCI etc... to do CD too.

[zendern]

Yeah for sure...if you pass it in then that is the value to be used. But nancy will attempt to "smart default" it for you.

[DarthHater]

Nancy is so clever!

[DarthHater]

I think we should create a ticket for this, it was a fantastic suggestion, however I dunno if I want to do it in this PR.

[zendern]

I assume you saw the tests are broken....looks like you can't run it via passing go.sum or Gopkg.lock anymore ¯_(ツ)_/¯

Also tests are a lacking in this PR but probably wouldn't hurt to add at least something around the cyclonedx stuff and maybe something around the api calls into IQ

[DarthHater]

@zendern yeah, I saw all that, gonna fix all that up tomorrow, just wanted to get some early feedback on my approach!

[zendern]

Re: squash into master. Nah that’s fine if you want to just do it that way. 👍

[DarthHater]

@fitzoh @zendern marking this as ready, I think it's more or less ready.

[DarthHater]

Bit of a follow up to, I'm noticing it's hard to test error cases in Nancy because we throw around os.Exit like it's going out of style (a mistake of mine). Does anyone have objection to using panic() more often like I've been doing here? It makes it easier to test in some cases (ok my function panic'd, etc...)

[zendern]

@DarthHater Latest changes look good to me. I do have a concern using panic and the fact that it now muddies user messaging when it is encountered. Basically it means two things....we lose control over the exit code coming back (maybe this is fine as long as it not 0 its fine) and we now give the user a stacktrace. Which sure nancy is a dev tool but feels like the wrong thing to show a user, most if any will not care about nancy internals.

So few options come to mind....

1. Ignore me and just roll with it....dev can handle a stack trace
2. We leave the panic to make it easier to test but need to catch the panic at the top level and not present that stacktrace to the user. And maybe that would be nice b/c in the future we could add a flag to debug and it would spit out the stacktrace ¯_(ツ)_/¯
3. Switch back to exit and change the test case to something like this. Where you spawn a subprocess test.
   https://stackoverflow.com/a/33404435

[DarthHater]

@zendern I'm with you on the stack trace stuff.

The convention in the Go libraries is that even when a package uses panic internally, its external API still presents explicit error return values.

I'm just trying to get more towards that, using panic in libs a bit more and allowing someone to recover if they want to, rather than explicitly force them to os.Exit

[zendern]

@DarthHater so then you plan is to put that into place?? So somewhere probably on main.go we capture the panic and return the message/correct error code

[DarthHater]

Well, I'm kinda stuck on it personally. The middle ground is probably to panic, and then recover by throwing an error from our public APIs, that's consistent with the golang principle anyways. More so having an open conversation so I can figure out how to wrap this PR up, while heading some sort of direction :)

[zendern]

@DarthHater sooooo middle ground maybe to get this pushed along. The panic stuff you are testing error states right?? What if we go back to exit, scrap the test you wrote around error path and write up an issue to move the project from exit -> panic and implement the public error handler code that would be needed. Eat the tech debt around error handling testing in this case and get this shipped ¯_(ツ)_/¯

[DarthHater]

That sounds good, bud. I'll see what I can move forward today and then re-tag you in here!

[DarthHater]

@zendern , moved back to errs and exits for now, if you wanna give this ole PR the rubber stamp!

[zendern]

[zendern]

^^^ @DarthHater don't make me approve again cause its not possible.