Calculate libyear

[edwinkortman]

Fixes #97

Technically this issue isn't done yet, but I figured I'd give it for review anyway.
What I've added is a few things to make calculating libyear possible for a given package url. The idea is that the Package URL comes from the Software Bill of Materials (CycloneDX file). With this package url we can use the dependency manager repository to query info about the package, specifically where it's versioned. Then we can find out when the tags have been published to get a release date for a specific version. There's a bit of a diagram in the issue #97 which I hope helps clarify things.

Why it's not done is because the repositories don't do anything yet. I'm working on making it work for at least one of them but it's starting to feel like that's growing beyond the scope of this issue, so I'd prefer to split the work here. I'll make issues for the remaining work if this okay with everyone? :-)

Left to do for this PR

• Make issues for the separate repositories once this is merged and team has agreed on taking that route

Solved
Another thing is that it's failing in Code Climate, but I don't entirely agree with the reason. It's tripping of similar blocks of code which they are but they test something vastly different. My suggestion here is to dial it down a little, if that's possible?

1

[Fact]
    public void It_can_not_instantiate_with_invalid_dependency_manager()
    {
        var caughtException =
            Assert.Throws<ArgumentException>(() =>
                SupportedDependencyManagers.FromString("prettysurethiscanneverwork"));

        Assert.Equal("Invalid dependency manager given 'prettysurethiscanneverwork'", caughtException.Message);
    }

2

[Fact]
    public void Verify_it_throws_exception_when_no_filepath_was_given()
    {
        var caughtException = Assert.Throws<ArgumentException>(() => _readCycloneDxFile.AsPackageURLs(""));

        Assert.Equal("Can not read file, as no file path was given", caughtException.Message);
    }

[mscottford]

Another thing is that it's failing in Code Climate, but I don't entirely agree with the reason. It's tripping of similar blocks of code which they are but they test something vastly different. My suggestion here is to dial it down a little, if that's possible?

That's really strange. I agree that those two methods don't appear similar to me. I think we should adjust the CodeClimate's duplication engine configuration to specify a higher "mass" value.

[edwinkortman]

Another thing is that it's failing in Code Climate, but I don't entirely agree with the reason. It's tripping of similar blocks of code which they are but they test something vastly different. My suggestion here is to dial it down a little, if that's possible?

That's really strange. I agree that those two methods don't appear similar to me. I think we should adjust the CodeClimate's duplication engine configuration to specify a higher "mass" value.

Thank you for the suggestion! :D I've added the threshold for similar code and '70' seems to be the sweet spot for this particular bit of similar code.

[mscottford]

Why it's not done is because the repositories don't do anything yet. I'm working on making it work for at least one of them but it's starting to feel like that's growing beyond the scope of this issue, so I'd prefer to split the work here. I'll make issues for the remaining work if this okay with everyone? :-)

I think this makes sense for now. The way that I think this should be implemented is to delegate to the freshli-agent-* programs. We should add a retrieve-release-history command to the each of the agent programs for this purpose. I think we can make that command take an option called --list-valid-purls which will output the PURL types that the command is able to retrieve history for. I've added an issue for the freshli-agent-java repository for this purpose.

So I think the process we would follow would be to run agents detect to find all of the agents, and then run each one of them with retrieve-release-history --list-valid-purls to determine the package urls that the agent supports, and then use this information for determining the correct agent that should be called to get the release history of a specific package by running retrieve-release-history package-url for each package that history information is needed for.

I'm assuming this information will make more sense in the issue that we create, but I wanted to write it out here while I'm thinking about it.

[mscottford]

I've got a couple of suggested changes to make, and I've made a couple of observations that should get moved into other issues.

[edwinkortman]

@mscottford I've processed your feedback, quite a few bits have changed. Could you have another look? :-)

[mscottford]

@mscottford I've processed your feedback, quite a few bits have changed. Could you have another look? :-)

You weren't kidding about "quite a few bits". :) I'm digging in now.

[mscottford]

This looks really good. Thanks for the time that you've put into it. I only have a few small changes that I would like to see implemented. And there are some spike issues that we need to do some investigations.

Much of this review as part of an ensemble session that included @donabp, @CodeMouse92, and @edwinkortman.

We agreed that as soon as the feedback was addressed it was okay to merge. :-)