License metric

[kevastator]

Resolves #17 .Finished adding some Markdown parsing checks!

[TylerSivertsen]

Sorry about taking so long to respond to this. I looked at it and I just had a couple questions/suggestion type things :

• I think you get the owner and repo from the url_parser that you made, I wasn't sure if you wanted to just use GraphQL to get those directly though? I think it's something like this

  const query = `
  query($owner: String!, $repoName: String!) {
  repository(owner: $owner, name: $repoName) {
    licenseInfo {
      key
    }
  }
  }
  `;

• I see that right now we are only checking for MIT, LGPL-2.1, BSD-3-Clause. Were there any more that we need to worry about and do we need to worry if someone has the license as like BSD 3-Clause or no?
• Do we need to worry about if the GraphQL query fails? (I think a try-catch line like below would fix it if we needed to?... but if we don't need to worry about it then it should be okay)

  try {
  var response = await graphqlRequest(query, { owner, repoName });
  var licenseName = response?.data?.repository?.licenseInfo?.key?.toUpperCase();
  } catch (error) {
  logger.error(`Failed to fetch license info for ${owner}/${repoName}: ${error}`);
  return [0, (new Date().getTime() - start) / 1000];  // Return 0 and elapsed time in case of failure (or whatever else we want to be the error)
  }

• I have seen some repos that have their overall branch as main instead of master is that just a naming convention thing or something we should check? (Something like this?)

  let responseMd = await fetch(`https://raw.githubusercontent.com/${owner}/${repoName}/master/README.md`);
  if (!responseMd.ok) {
  responseMd = await fetch(`https://raw.githubusercontent.com/${owner}/${repoName}/main/README.md`);
  }

  That's all I could try to be critical of (this looks great, and I know you put a lot of work in it, I am just trying to play devil's advocate)

[kevastator]

I will reply to each issue in order:

• Yes each graph ql based metric should use owner name and repo name to make the call. It works as intended from url_parser results.
• Using the slide we found in our report those are the three that are compatible (according to the slide) Prof said there are many lists that have such rules, so we have justification in our report. The keys will also be consistent from the returned value for string parsing.
• I think the graph ql call has checks in itself. But it's not a bad idea to incorporate this idea in all our metrics: I will create a future branch for such error catching.
• I love this idea, I will add this fix

Thanks for the great ideas. I will add some and submit a pull request with the changes in mind!