Save issue Labels with issues returned by IssueFinder.findIssues

[DuaneOBrien]

We pass IssueFinder.findIssues a GitHubToken, a list of Labels, and a list of Repos. We get back from IssueFinder.findIssues an array of issues, each of which looks something like this:

    {
      "title": "\"Filtering\" should support permalinks",
      "createdAt": "2020-10-04T20:27:34Z",
      "repositoryNameWithOwner": "indeedeng/k8dash",
      "url": "https://github.com/indeedeng/k8dash/issues/153"
    }

We should persist the labels that applied to the issue and include them in each issue, something like:

    {
      "title": "\"Filtering\" should support permalinks",
      "createdAt": "2020-10-04T20:27:34Z",
      "repositoryNameWithOwner": "indeedeng/k8dash",
      "url": "https://github.com/indeedeng/k8dash/issues/153",
      "labels": ["hacktoberfest", "good+first+issue"]

    }

This would allow us to filter output for specific issue types and provide additional helpful context for issues output by Mariner.

[kevindigo]

This makes a lot of sense. Are there other data fields that we should also include in the output? I think this is the page describing what is at least in theory available: https://developer.github.com/v4/object/issue/

[DuaneOBrien]

Good question. The only other field I think I could see using is updatedAt, though body wouldn't be far behind.

I could see an argument for capturing the whole set of issue information, but I think over thousands of repos this would be a sizable problem.

For now, I think just labels and updatedAt. That would keep the output data fairly slim.

[kevindigo]

Sounds good. I think adding updatedAt would be pretty easy. Labels will be trickier because the graphql query will have to navigate the tree of returned data. It would be a good chance for someone to get experience with graphql.

[DuaneOBrien]

We should still know what label was being searched for when we're parsing the results of the query, shouldn't we?

[kevindigo]

We should still know what label was being searched for when we're parsing the results of the query, shouldn't we?

Indirectly, yes. But it's weird because we search one label at a time. I'm inclined to think that the results should include ALL of the labels for each issue. Then to generate the final output, the calling code could filter them to only list those that intersect with the array of labels that was passed in.

[redgardner]

I'd be interested in helping out with this ticket.

[kevindigo]

Great! I have assigned it to you. Please let us know if you have any questions.

[redgardner]

Would y'all be open to tagging this with the hacktoberfest label?

[kevindigo]

@redgardner : I meant to ask if you would like that tag. Hopefully I did it correctly. (It's my first time.)

[redgardner]

@kevindigo Thanks! Just finished putting up a PR. Just wasn't sure how many labels should be fetched, I ended up doing 100, but didn't fetch another page.

[redgardner]

Looks like a label for the repository is also needed. In the Hacktoberfest UI:

Your PR was submitted to a repository that is not participating in Hacktoberfest. Maintainers of the repository can add the "hacktoberfest" topic to their repository if they wish to participate.

[danisyellis]

The way to get @redgardner credit without having to label the entire repo hacktoberfest is to put a label in the PR, not the issue.
When you accept the PR @kevindigo add the ‘hacktoberfest-accepted’ label to the PR before closing it.

[kevindigo]

Thanks dani! We had intended to tag this repo with hacktoberfest earlier, but I/we weren't prepared to handle an onslaught of PRs. At this point in October, I think having the repo tagged should be safe, so I added it last night. Hopefully correctly If it causes problems, I'll fall back to the steps you outlined. And if the repo tag isn't working, I can tag the PR.