Closed skanda890 closed 2 months ago
See the :open_file_folder: files view, the :scroll:action log, or :memo: job summary for details.
whitesource
I'll need to have an engineer check Mend Bolt out before merging this PR.
URL for Mend Bolt:https://www.mend.io/free-developer-tools/bolt
We already have internal infrastructure that handles the same type of reporting that Mend Bolt appears to be doing, and it is required that we leverage it. I would prefer not to add a 3rd party action (mild risk) that does the same (no apparent gain).
But after using Mend Bolt for some time with other apps like Mend Bolt, I feel like Mend Bolt is better and is the best out of all.
@skanda890 I can appreciate the familiarity with other tools and the things they provide. Rather than adding another layer of complexity which comes with potential performance limitations (5 calls / day with Mind Bolt) and the potential for other complex interactions, I'd ask what Mind Bolt is doing that we're not doing with our internal tooling to see if we can cover differences that way.
Given the response from our engineering team, I would not merge this PR and add Mind Bolt.
What service do you use? If I get this I can compare the features between them.
It's an internal set of tools. They are designed to ensure we're complying with all of our company policies. The bigger question I'd ask is what value does the tool you proposed provide? Let's assume the software vulnerability detection is handled by the tooling we use today.
Okay, leave that, what about the other things?
@skanda890 PRs should focus on a "single" change or request. That means keeping them to "one" logical topic and have a single issue they resolve. Continuing to modify the PR causes churn.
I'd also suggest making PRs as draft until they are actually ready for review to be merged.
The images for the icons will not be accepted as these are the official images. Any changes run the risk of changing how they are displayed as the image formats are not lossless.
We love the enthusiasm and welcome improvements, but it's hard to reason about unrelated changes. Smaller PRs are easier to fully understand and review, which means they are more likely to get merged.
/azp run
@yao-msft, I have made some changes. Kindly review them.
The changes for Microsoft.Posershell.SDK should be a separate pull request. It is best to keep each pull request limited to a single set of similar changes instead of grouping multiple changes into a single PR
To: @Trenly
🌟 Ode to My PR Mishap 🌟
Oh, tangled branches of my git tree, How thou dost vex me with thy entwined changes! Forgive me, dear reviewer, for my folly, As I seek redemption in separate PRs.
Let each branch stand alone, proud and distinct, Like constellations in the midnight sky. And may our codebase sing harmoniously, Free from the cacophony of tangled diffs.
@Trenly, grant me this chance— To untangle my commits, like a patient weaver, Crafting a quilt of elegance and clarity.
In this digital realm, where bits converge, Let our apologies be sincere, our PRs pristine.
This is the first PR poetry I've ever heard of!
Do you guys have any tips on where to contribute or any open repositories where I can contribute?
It really depends on what your "goal" is. It could be better to go a bit deeper into code on a smaller number of projects rather than to scatter across a larger number of projects. Every project is going to have its own community and set of standards. There are lots of different ways to contribute as well. Sometimes just doing work on documentation adds massive value, other times it might be fixing bugs or adding features. It just depends on why you're wanting to contribute.
It really depends on what your "goal" is. It could be better to go a bit deeper into code on a smaller number of projects rather than to scatter across a larger number of projects. Every project is going to have its own community and set of standards. There are lots of different ways to contribute as well. Sometimes just doing work on documentation adds massive value, other times it might be fixing bugs or adding features. It just depends on why you're wanting to contribute.
My goal is just to contribute to an open repository.
Summary of the PR
Update dependencies and more.
Microsoft Reviewers: Open in CodeFlow