Closed kingdonb closed 1 year ago
An alternative approach could be to use the KEDA cron scheduler, some discussion of that here:
This is working now, after 0.0.3 (which is the first release to include stat.wasm
as a downloadable artifact)
See here: https://github.com/kingdonb/stats-tracker-ghcr/actions/runs/5390668110/jobs/9786362749#step:6:307
We should see it running at 2 minutes after the hour from now on. 🎉 the commit which ultimately finished this was aad13b4
Waiting until it runs on schedule for the first time to close, we should be able to tell for sure in about 5 minutes.
It's definitely working ✅
The dev instance is on a vcluster at my house, now it turns out to be much faster than the EKS cluster we had used in the cloud. Not sure why, though that's interesting, I don't really want to have production hosted out of my house.
We had talked that we could use a
kind
cluster in a GitHub Actions to test this project from end-to-end, and if we did that, what's to stop us from hooking it up to the production database and putting it on a schedule, we can call that production, et voila?So the dev instance can stay where it is, we'll use neon tech database for production (as already discussed in #11), and production can run in GitHub Actions, with a regular schedule of once an hour, 12 hours a day for six days a week! It's OK to have one day of outage in production each week. It's OK to shut production down at night. (I don't want to be on GitHub Actions' bad side.)