Automatic running of crowdmatches on schedule #163

wolftune commented 2019年05月23日 01:45:32 +02:00

We need to determine the specs for this. How flexible should this be? What tests are needed? Etc

Currently crowdmatches are just run manually.

Blocked on #629

Implementation

A cron job should be fine. Use date to calculate the precise dates/times to run the crowdmatch at.

We need to determine the specs for this. How flexible should this be? What tests are needed? Etc Currently crowdmatches are just run manually. Blocked on #629 ## Implementation A cron job should be fine. Use `date` to calculate the precise dates/times to run the crowdmatch at.

wolftune commented 2019年06月17日 02:41:21 +02:00

marked this issue as related to #162

marked this issue as related to #162

wolftune commented 2019年09月13日 00:10:44 +02:00

mentioned in merge request snowdrift/snowdrift!170

mentioned in merge request snowdrift/snowdrift!170

wolftune commented 2019年09月15日 21:41:15 +02:00

mentioned in merge request snowdrift/snowdrift!171

mentioned in merge request snowdrift/snowdrift!171

smichel17 commented 2021年07月09日 02:00:18 +02:00

marked this issue as related to #171

marked this issue as related to #171

smichel17 commented 2021年07月09日 02:08:46 +02:00

Now that the process is documented, I don't think we will fall so far behind again, so I'm going to de-prioritize this.

Specs discussion for the crowdmatch itself is in https://gitlab.com/snowdrift/snowdrift/-/issues/171, but there's a separate issue of how the automated process should behave if, for example, there's an error for some reason.

Now that the process is documented, I don't think we will fall so far behind again, so I'm going to de-prioritize this. Specs discussion for the crowdmatch itself is in https://gitlab.com/snowdrift/snowdrift/-/issues/171, but there's a separate issue of how the automated process should behave if, for example, there's an error for some reason.

smichel17 commented 2021年07月09日 02:23:43 +02:00

I think for now, sending an email to community@ or admin@ would probably be enough. If email is down for the same reason it fails, then someone will notice that the crowdmatch wasn't run that month and can catch up manually. Actually, it should probably send an email on either success or failure — easier to notice that way.

We should also make sure its error messages are logged somewhere besides just email, but that's part of a larger process of streamlining our sysadmin/ops/monitoring, so I don't think we need to worry about it here.

The one thing we need to be certain of is that the crowdmatch won't be run more than it is supposed to, since I'm not sure if there is any duplicate prevention in the Haskell at the moment.

I think for now, sending an email to community@ or admin@ would probably be enough. If email is down for the same reason it fails, then someone will notice that the crowdmatch wasn't run that month and can catch up manually. Actually, it should probably send an email on either success or failure — easier to notice that way. We should also make sure its error messages are logged somewhere besides just email, but that's part of a larger process of streamlining our sysadmin/ops/monitoring, so I don't think we need to worry about it here. The one thing we need to be certain of is that the crowdmatch won't be run *more* than it is supposed to, since I'm not sure if there is any duplicate prevention in the Haskell at the moment.

smichel17 commented 2025年10月21日 16:21:50 +02:00

Ok so normally I'd just add an [ana]crontab entry for this.

@monthly 45 crowdmatch /path/to/crowdmatch "$(date +%Y-%m-01)"

However, the server itself is managed by OSUOSL, so I don't want to touch system files, since they would be lost if they needed to rebuild the VM for whatever reason. We could add the cron entry in the OSUSOL cookbook for the VM, but then it would be hard to change, and I'd really prefer the definition to live in the snowdrift code base anyway.

So I need to figure out how to get keter to execute the right commands on redeploy to put a cron config or similar at a static location, and update the cookbook to execute any crontabs at that location? Or find a different way to do things, but not using keter would increase the scope of the issue a lot.

I'd appreciate opinions or feedback on this.

Ok so normally I'd just add an [ana]crontab entry for this. `@monthly 45 crowdmatch /path/to/crowdmatch "$(date +%Y-%m-01)"` However, the server itself is managed by OSUOSL, so I don't want to touch system files, since they would be lost if they needed to rebuild the VM for whatever reason. We _could_ add the cron entry in the OSUSOL cookbook for the VM, but then it would be hard to change, and I'd really prefer the definition to live in the snowdrift code base anyway. So I need to figure out how to get keter to execute the right commands on redeploy to put a cron config or similar at a static location, and update the cookbook to execute any crontabs at that location? Or find a different way to do things, but not using keter would increase the scope of the issue a lot. I'd appreciate opinions or feedback on this.