chore: Subgraph monitoring action

[brunomenezes]

Summary

The addition of a new schedule action to keep monitoring delays in the indexed blocks in all hosted subgraphs we have. It has a threshold configured (currently 50 blocks). If any of the checked deployed subgraphs exceed that limit in terms of difference, the action will create an issue and mention the team cartesi/explorer so the people in that team will be notified.

Requirements:

• A registered GitHub App with required permissions, followed by installing it in the Org and mapping the repository.

Reference: https://github.com/orgs/community/discussions/43415#discussioncomment-9941115

ps: without the permissions, the bot will mention the team, but GitHub will not schedule an email

[brunomenezes]

I am leaving as a Draft as I need a GitHub App installed at the organisation level for this to work as intended (Check the reference link in the description for details).

@tuler, Let's create the GitHub App? Without it, it's only possible to create a GitHub issue, but the team mentioned will not work as intended, that is, to have the members receive an email.

[tuler]

@tuler, Let's create the GitHub App?

I feel that creating a GitHub app only for this is an overkill. It doesn't feel like GitHub apps are meant for that, or meant to be created for a single purpose like this.

Are there any simple monitoring solutions that could host this check?

[brunomenezes]

@tuler, Let's create the GitHub App?

I feel that creating a GitHub app only for this is an overkill. It doesn't feel like GitHub apps are meant for that, or meant to be created for a single purpose like this.

As I understood from the discussion in the reference link, that is what a GitHub app is intended to do: provide approved permissions so the Action can proceed with its steps without using personal tokens, etc. It is not overkill, since every GitHub app installed in a repo or org must be approved to obtain permissions.

The other option, without notification, is to remove the app need piece and create the issue without mentioning the team. From time to time, members can check whether there is a GitHub issue.

Are there any simple monitoring solutions that could host this check?

When we discussed, you suggested GitHub Actions. So, what is your suggestion for a more self-contained solution?

[tuler]

As I understood from the discussion in the reference link, that is what a GitHub app is intended to do: provide approved permissions so the Action can proceed with its steps without using personal tokens

I mean, GitHub Apps are much more than that.

https://docs.github.com/en/apps/creating-github-apps/about-creating-github-apps/about-creating-github-apps

Are there any simple monitoring solutions that could host this check?

When we discussed, you suggested GitHub Actions. So, what is your suggestion for a more self-contained solution?

Maybe @endersonmaia has a better idea. We only need to run a simple script every 5 minutes and notify some people, through any means.

[brunomenezes]

I mean, GitHub Apps are much more than that.

https://docs.github.com/en/apps/creating-github-apps/about-creating-github-apps/about-creating-github-apps

I know and that is the type of GitHub App we would be registering: https://docs.github.com/en/apps/creating-github-apps/about-creating-github-apps/about-creating-github-apps#github-apps-that-act-on-their-own-behalf

Maybe @endersonmaia has a better idea. We only need to run a simple script every 5 minutes and notify some people, through any means.

Sure! Let's see the option(s) and settle on one.

[brunomenezes]

Oh! Just one thing to consider @endersonmaia, is that my current solution covers the situation of team members added or removed from the team. As such, if someone is removed from cartesi/explorer, they are automatically removed from the mailing list, and vice versa.

cc: @tuler

[endersonmaia]

Considering that the proposed workflow involves creating a GitHub Issue, I think it's ok to have a GitHub App for that.

And any other solution I could think of would require hosting some othewr service elsewhere, which adds unnecessary complexity to such a simple requirement.