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

DotNet 3 #176

Merged
merged 18 commits into from Jun 2, 2020
Merged

DotNet 3 #176

merged 18 commits into from Jun 2, 2020

Conversation

gkillough
Copy link
Contributor

Description

  • Added functionality to determine available dotnet runtimes and programmatically select the appropriate nuget inspector.
  • Added several abstractions for duplicate nuget functionality.

@blackduck-copilot
Copy link

blackduck-copilot bot commented May 27, 2020

Black Duck Security Report

Merging #176 into master will not change security risk.

Added Components

Clean: 1

Removed Components

Clean: 1

Click here to see full report

import com.synopsys.integration.detectable.detectable.executable.ExecutableRunner;
import com.synopsys.integration.detectable.detectable.executable.ExecutableRunnerException;

public class NugetRuntimeResolver {
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd rather we separated the invocation of the command from the parsing and matching - it would make the unit tests simpler.

@gkillough gkillough marked this pull request as ready for review May 28, 2020 12:48
}

public boolean isRuntimeAvailable(Integer... versionTokens) throws DetectableException {
List<String> runtimes = dotNetRuntimeFinder.listAvailableRuntimes();
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this is improved, but I think we could isolate more if you take in a List runtimes instead of taking the DotNetRuntimeFinder.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The reason I was hesitant about doing something like that is that it would allow you to pass in an arbitrary list of Strings. Even if we wrapped those Strings in a new type of object (e.g. DotNetRuntimeModel or something), I think these are concerns that are already correctly coupled. Decoupling further would essentially make this a semVer regex util that just so happens to have a constant pattern related to dotnet runtimes. If we want to go that route, that's fine (obviously we would move the runtime pattern constant somewhere else), but I think that is what we're really talking about if we decouple this further.

Copy link
Contributor

Choose a reason for hiding this comment

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

Gotcha, I can say it is very typical for parsers to take in a list of strings, such as NpmParser. And it is convention we know you can't just pass an arbitrary list of strings. That said I would not be opposed to a small data class like DotNetRuntimeResult(List runtimes).

Personally not having to create a mock runtime executable and eliminating the explicit dependency outweigh protecting someone from passing wrong strings. But I would also be fine with what you have. Depends on the type of change that comes in next.

@@ -139,7 +141,7 @@ public AirGapPathFinder airGapPathFinder() {

@Bean
public CodeLocationNameGenerator codeLocationNameService() {
final String codeLocationNameOverride = detectConfiguration.getValueOrEmpty(DetectProperties.Companion.getDETECT_CODE_LOCATION_NAME()).orElse(null);
Copy link
Contributor

Choose a reason for hiding this comment

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

Not in love with removing all the finals, but since we don't have an official rule on it, it's fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

My save actions are configured based on the Engineer Onboarding on Confluence, but if you guys have a different preference in Detect, I can update the settings for the project accordingly. I assumed the finals were just left over from when we still had that convention mandated.

Copy link
Contributor

Choose a reason for hiding this comment

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

If you could add them back for now that would be great.

@@ -139,7 +141,7 @@ public AirGapPathFinder airGapPathFinder() {

@Bean
public CodeLocationNameGenerator codeLocationNameService() {
final String codeLocationNameOverride = detectConfiguration.getValueOrEmpty(DetectProperties.Companion.getDETECT_CODE_LOCATION_NAME()).orElse(null);
Copy link
Contributor

Choose a reason for hiding this comment

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

If you could add them back for now that would be great.

final String inspectorExe = foundExe.get().getAbsolutePath();
logger.debug("Found nuget inspector: " + inspectorExe);
return new ExeNugetInspector(executableRunner, inspectorExe);
Optional<File> foundExecutable = fileFinder.findFiles(toolsFolder, inspectorName, 3).stream().findFirst();
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
Optional<File> foundExecutable = fileFinder.findFiles(toolsFolder, inspectorName, 3).stream().findFirst();
File foundExecutable = fileFinder.findFiles(toolsFolder, inspectorName, 3).stream().
.filter(File::exists)
.findFirst()
.orElseThrow(() -> new DetectableException(String.format("Unable to find nuget inspector, looking for %s in %s", inspectorName, toolsFolder.toString())));

Copy link
Contributor

Choose a reason for hiding this comment

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

I think we don't need the if/else if we do the filtering in the Stream.

@JakeMathews
Copy link
Contributor

Also the battery tests seem to be failing on Travis. Not sure if it is a result of the changes you made, or if the changes on master just need to be merged with this branch.

@gkillough
Copy link
Contributor Author

Also the battery tests seem to be failing on Travis. Not sure if it is a result of the changes you made, or if the changes on master just need to be merged with this branch.

@JakeMathews It's because the new inspector isn't released on artifactory yet.

@sonarcloud
Copy link

sonarcloud bot commented Jun 2, 2020

Kudos, SonarCloud Quality Gate passed!

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities (and Security Hotspot 0 Security Hotspots to review)
Code Smell A 1 Code Smell

15.5% 15.5% Coverage
0.0% 0.0% Duplication

warning The version of Java (1.8.0_151) you have used to run this analysis is deprecated and we will stop accepting it from October 2020. Please update to at least Java 11.
Read more here

@gkillough gkillough merged commit fa3da79 into master Jun 2, 2020
@JakeMathews JakeMathews mentioned this pull request Jun 4, 2020
@gkillough gkillough deleted the gk_support_dotnet_3 branch June 10, 2020 16:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants