-
Notifications
You must be signed in to change notification settings - Fork 499
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
✨ Initial experimental Azure DevOps client #4377
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4377 +/- ##
==========================================
- Coverage 66.80% 59.36% -7.44%
==========================================
Files 230 216 -14
Lines 16602 16371 -231
==========================================
- Hits 11091 9719 -1372
- Misses 4808 5948 +1140
- Partials 703 704 +1 |
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's the MVP for a scorecard scan to complete without panicing.
panicing, or completing without runtime errors? What's the manual testing of this look like for the maintainers? Are there any world-public azuredevops repos?
I'd like to get feedback at this stage, before I implement the remainder of the client.
In general, the pattern is good. You copied the existing structure, and you're working through it piece by piece.
Did you plan on finishing the client in this PR or followups? Breaking it up in separate PRs may be easier. Your first approach was "run scorecard without panicing", but I think a good next step is "run a specific check"
So start with something like go run main.go --repo <blah> --checks Maintained
, which just needs some info about the repo, commits, and issues. Code-Review is probably in this group too.
Then you can move on to checks which need file content (Binary-Artifacts may be a good one?), and then some of the more involved ones that rely on CI/CD data etc.
There's a lot of linter errors that I'm sure you're waiting to resolve until after your approach got reviewed. So I didn't review any of that sort of thing, happy to give tips if desired. |
Completing without runtime errors. Here's the output, running against https://dev.azure.com/jamiemagee/jamiemagee/_git/jamiemagee, after my most recent changes: Details
I think I'd like to finish the client in a followup PR if that's possible? I think it'd be easier for you to review in smaller chunks instead of one, big bang, pull request. I plan to attend the scorecard APAC meeting on Thursday to gauge interest as well.
I'll tackle those in the next day or two. Thanks so much for the review! |
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 I'd like to finish the client in a followup PR if that's possible? I think it'd be easier for you to review in smaller chunks
Agreed. I went ahead and approved the boilerplate, pending linter fixes.
There's a lot of linter errors that I'm sure you're waiting to resolve until after your approach got reviewed. So I didn't review any of that sort of thing, happy to give tips if desired.
I'll tackle those in the next day or two.
make fix-linter
may help with some auto-generated fixes.
Anything that complains about struct alignment you can usually fix with
go install golang.org/x/tools/go/analysis/passes/fieldalignment/cmd/fieldalignment
fieldalignment -fix ./clients/azuredevopsrepo
Happy to help with any others as well.
also your latest commit wasn't DCO'd. that will also be a blocker. The checkrun will have remediation info: |
2208766
to
ebd485a
Compare
@spencerschrock I think I've addressed all your comments. If so, this should be ready to merge. |
This pull request has been marked stale because it has been open for 10 days with no activity |
I've been out on the office on personal time, will take a look in the next day or two. |
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 one small clarification to what I meant by "caching".
Signed-off-by: Jamie Magee <[email protected]>
Signed-off-by: Jamie Magee <[email protected]>
Signed-off-by: Jamie Magee <[email protected]>
Signed-off-by: Jamie Magee <[email protected]>
ebd485a
to
6044d50
Compare
Signed-off-by: Jamie Magee <[email protected]>
6044d50
to
ecf43e0
Compare
Wooo, thanks for this contribution, @JamieMagee! |
What kind of change does this PR introduce?
This PR introduces early experimental support for Azure DevOps. It's the MVP for a scorecard scan to complete without panicing.
What is the current behavior?
No Support for Azure DevOps repository scanning
What is the new behavior (if this is a feature change)?**
This is a followup from #4178, and the next step for #4177. It is the minimal client implementation for Azure DevOps repository support.
I'd like to get feedback at this stage, before I implement the remainder of the client.
Which issue(s) this PR fixes
Continued work on #4177
Special notes for your reviewer
This change is currenltly gated behind the
SCORECARD_EXPERIMENTAL
environment variable, same as the initial GitLab client was.Does this PR introduce a user-facing change?
For user-facing changes, please add a concise, human-readable release note to
the
release-note
(In particular, describe what changes users might need to make in their
application as a result of this pull request.)