Usage with GitHub Action

[ribtoks]

Hi

Thank you for developing cState!

I think it should be possible to have this monitorbot configured as a GitHub action that will run in the repository with a status website. It will have most permissions out of the box (with default $github.token) and will be very valuable! My question is - if that makes sense, would you mind creating an example, as you know how is most correct to set up this project?

[mistermantas]

Hi. Running this as a GitHub Action is a fantastic idea. It would make setup way easier for a lot of people by getting rid of the need to have a server running 24/7.

I've been thinking about what it would take to make that happen. Right now, the bot is built to be a long-running service you host yourself, using node-cron to check stuff every few seconds. BUT:

1. GitHub Actions can only run every 5 minutes at most. Our current setup can check every 5 seconds. For users who need instant alerts, that's a deal-breaker.
2. The bot currently keeps track of failures in memory (for the escalationThreshold). A GitHub Action is stateless, so every run is a fresh start. We'd have to start saving the state to a JSON file and committing it back to the repo, which adds a new layer of complexity.
3. Monitors like diskSpaceMonitor or memoryMonitoring may not work anymore, since the environment is the temporary GitHub runner.

What a rewrite would look like:

• Kill the internal cron job: The script would need to be refactored to just run once and then exit.
• Build a state manager: It would need to read/write its state (like "is this site already down?") from a file in the repo.
• Create the .yml workflow: This would be the new "scheduler" that tells GitHub to run the script every 5 minutes and handle committing the status page updates.
• Update the docs: We'd need a whole new section explaining the two different ways to run the bot.

Because this touches the whole architecture, this is a major feature request.

I'm keeping this issue open. If anyone wants to make a PR faster than me, go ahead.

[ribtoks]

Hi. Thank you for your response.

1. I think 5 minute is not a deal breaker - it really depends on the use-case. For me 5 minutes is perfect.
2. GitHub Actions have cache which they can save and restore, so if the bot can save state to an SQLite file, it will solve it. SQLite is already an overkill, if we are talking about a single monito - which can be, then, a single file.
3. I think it's OK. I assume most people are interested in only ping (availability) monitoring. In my opinion this tool is not suitable to monitor disk space or memory because there're much better tools for that (e.g. NetData, Prometheus etc.)

To summarize, I don't think a rewrite is really required (although it's possible of course). What do you think can be a minimal possible change that would unlock this functionality (even at 5 minute step) at all?

[mistermantas]

This software doesn’t support GitHub actions at the moment is what I’m saying.

When the feature is added I’ll tag you and let you know. Unless you want to take a stab at that yourself

[yurivanmidden]

I've actually gone and implemented this in Gitlab pipelines (mostly as an experiment, but the scheduled pipelines run reliable enough for me and it might be a stayer henceforth).

I cloned the repo and made use of the caching functionality between pipeline runs to monitor the incident rate.
Steps to reproduce look something like this:

1. In index.js I removed the cron functionality at the end of the file, so that it runs once and then quits.
2. Cache the following paths between the pipeline jobs:

paths:
  - monitorbot/node_modules/
  - monitorbot/incident_state.json

3. In the pipeline I run within the oven/bun:alpine image:
   First bun install --no-save and then bun index.js.
   I run this pipeline scheduled every 20 minutes (which is enough for me). Incidents are committed to my cstate repository, and deployed as static Gitlab Pages. One run takes a mere 15 seconds, hence only costs a few compute minutes every day.

If you're interested I could make a PR for this to incorporate this functionality in the mainstream code?

[yurivanmidden]

I opened a pull request for what I described above, but for the GitLab Pipelines. I might extend it with Github Actions later, but I'm not familiar with Github Actions atm so that would take a little research on my side ;).

Feedback is appreciated.

[mistermantas]

I opened a pull request for what I described above, but for the GitLab Pipelines. I might extend it with Github Actions later, but I'm not familiar with Github Actions atm so that would take a little research on my side ;).

Feedback is appreciated.

This is merged, if the community makes a pr for GitHub I'll merge it also