ci: new github action which logs all the reactions in prs and issues

[14Richa]

Description
A GitHub action that calls API on every issue and PR and labels (community-attention) in the issues and PR which have more than 5 reactions.

Pre-requisite
Ensure the label we are trying to add ("more than 5 reactions") already exists in the repository.
If it doesn't exist, you'll need to create it first using the GitHub web interface.

Related issue(s)

Resolves: #41

[github-actions]

Welcome to AsyncAPI. Thanks a lot for creating your first pull request. Please check out our contributors guide useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[derberg]

looks good but can this be done with https://github.com/actions/github-script and not curl and bash?

script action already contains GitHub REST Client

[derberg]

few final questions

also, is there a repo where you test it that code works?

[derberg]

@KhudaDad414 can you also have a look at this workflow?

I was thinking if maybe we should first add it to only one repo, to see how it works 🤔

[KhudaDad414]

Do we have an estimation of how many API calls will it make for all repos?

[KhudaDad414]

@derberg I tested this in my fork and everything seems to be in order so I don't see the point. 🤔

[14Richa]

Do we have an estimation of how many API calls will it make for all repos?

Hey Khuda, yes we do have.

One API call per repo, then as many calls as issues with reactions > 10 we have in a repo, and the same with PR.

[derberg]

@14Richa it is actually more. Single request fetch no more than 100 issues (I don't know what is the default per_page but max is 100) so in one repo like website it can be even 15 calls.

in UI I can query for issues that have a certain amount of reactions: https://github.com/asyncapi/website/issues?q=is%3Aissue+reactions%3A%3E5

so if REST API does not enable you to do this, maybe GraphQL API will?

---

one small concern I have is that reactions that we change for now in this PR are the reactions on issue, but there can be reactions to the individual comment.

[14Richa]

@14Richa it is actually more. Single request fetch no more than 100 issues (I don't know what is the default per_page but max is 100) so in one repo like website it can be even 15 calls.

in UI I can query for issues that have a certain amount of reactions: https://github.com/asyncapi/website/issues?q=is%3Aissue+reactions%3A%3E5

so if REST API does not enable you to do this, maybe GraphQL API will?

one small concern I have is that reactions that we change for now in this PR are the reactions on issue, but there can be reactions to the individual comment.

Uhm, I see. Let me think more about this.

[14Richa]

@14Richa it is actually more. Single request fetch no more than 100 issues (I don't know what is the default per_page but max is 100) so in one repo like website it can be even 15 calls.

I agree. I guess we'd have to loop over the paginated results.

in UI I can query for issues that have a certain amount of reactions: https://github.com/asyncapi/website/issues?q=is%3Aissue+reactions%3A%3E5
so if REST API does not enable you to do this, maybe GraphQL API will?

I think the GitHub GraphQL API does not provide a direct way to filter issues based on the number of reactions.

one small concern I have is that reactions that we change for now in this PR are the reactions on issue, but there can be reactions to the individual comment.

Agree with this. I modified the GitHub action on my local repo to test it. It works fine but it increases the API calls and the filtering still happens client side.

[derberg]

I agree. I guess we'd have to loop over the paginated results.

pagination plugin that you use there already handles that, just make sure page size is max

Agree with this. I modified the GitHub action on my local repo to test it. It works fine but it increases the API calls and the filtering still happens client side.

yeah, I bet the amount of calls multiply a lot

I think the GitHub GraphQL API does not provide a direct way to filter issues based on the number of reactions.

I just tried search and worked well:

query { 
  search(query: "org:asyncapi reactions:>10", type: ISSUE, first:100) { 
    issueCount
    edges{
      node {
        ... on Issue {
          url
        }
      }
    }
  }
}

result

{
  "data": {
    "search": {
      "issueCount": 6,
      "edges": [
        {
          "node": {
            "url": "https://github.com/asyncapi/website/issues/903"
          }
        },
        {
          "node": {
            "url": "https://github.com/asyncapi/cli/issues/251"
          }
        },
        {
          "node": {
            "url": "https://github.com/asyncapi/brand/issues/1"
          }
        },
        {
          "node": {
            "url": "https://github.com/asyncapi/spec/issues/618"
          }
        },
        {
          "node": {}
        },
        {
          "node": {
            "url": "https://github.com/asyncapi/spec/issues/94"
          }
        }
      ]
    }
  }
}

but now I'm thinking.... @KhudaDad414 aren't you actually doing it in your community dashboard for hot issues?

with such search query we do not need the action to run in all repos, but just in one. Still no solution for comments....

[14Richa]

I just tried search and worked well

I see, I didn't know about that way. I had tried and couldn't find a neat way to add filter from the nested totalCount.

query {
  search(type: ISSUE, query: "") {
    issueCount
    edges {
      node {
        number
        title
        reactions(first: 100) {
          totalCount
        }
      }
    }
  }
}

    ```

[KhudaDad414]

@derberg, yes we are using search for the dashboard and it is awesome (very low points for api calls).

@14Richa have you checked https://github.com/asyncapi/website/blob/master/scripts/dashboard/issue-queries.js ? there are some queries that might be helpful. also since you are going to query the reactions on the comments as well, it can consume more points which need to be tested.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this pull request, add a comment with detailed explanation.

There can be many reasons why some specific pull request has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this pull request forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️