Shift GitHub to check for updates every Sunday and build 2nd Saturday of each month

[marionbarker]

Purpose

Try to avoid times when GitHub actions are historically busy.
Thanks Carol Vachon for this report:

The most significant and consistent historic pattern impacting GitHub activity is the week-to-weekend cycle, as most development work happens during the standard workweek.

• Lowest activity: Weekends, especially Sundays, see the least amount of activity, as most developers are off work.
• Highest activity: Activity is typically at its peak from Tuesday to Thursday.
• Moderate activity: Mondays and Fridays have moderate activity as developers ease into and out of the workweek.

On Wed, Oct 1, GitHub actions were impacted and all builds across the Open Source community all failed.

edited to add - we made a mistake - this ran the build process every day from the 8th through the 14th. See #470 for the fix to this mistake.

Method

• Shift the weekly build in case of code updates from Wednesday to Sunday
• Shift the monthly builds, regardless of whether code was updated, from the 1st of the month to the second Saturday of each month

[oddst]

I believe that the DIY diabetes apps automatic actions should be spread more than this suggestion. Every business tries to avoid unnecessary costs, and GitHub is not different. The free macOS runners are a limited resource with GitHub (since it probably is costly to GitHub), and we probably need to spread these actions out as much as possible - without it becoming a complete administrative nightmare.

Having all of the different apps with automatic actions on the same day or the same date, is most likely not sustainable. This has to be spread more, and this should also be possible to spread out more.

We should list the apps based on the number of forks in GitHub, and prioritize them accordingly.

LoopWorkspace is probably the app that has the most users and as such it should be put at the most optimal day/date/time that are available to us. Convenience and practicality probably should yield.

Based on the number of forks, the apps should be spread out as much as possible. There should probably be around 5-6 hours between each batch that is running - since I have observed some actions waiting for more than 4 hours for resources. This is not necessarily obvious when you see the run statistics afterwards, as I believe having been queued does not show afterwards only the time used for processing.

If it is possible to get statistics from GitHub about the use of macOS runners (but maybe also the Ubuntu runners that are in some limited use), that information might be helpful.

It is also important to take into account the countries using these runners the most, and the timezone they are in.

But if we assume that US is the biggest user, then this should affect the day/time chosen. Night to Monday is probably a very good time. The same goes for the first 12 hours of Saturday and Sunday. We can put smaller apps (more limited forks) into Friday evening maybe...?

We should not put anything into the working days preferably, or within extended working hours on the working days - Monday morning and Friday afternoon as possible exceptions.

Use Night to Sunday and Night to Monday for Weekly code check and possible building.

Use multiple dates (like 9th, 11th, 13th) devided between apps, for automatic building (and now also code update). Make sure this happens during the night to these dates...!

I would also avoid having code update and possible build (currently Wednesdays) take place on the same date as building (that now also include code update). The opposite happened now on Wednesday October 1st. We should look into the possibility to avoid that.

If we need to spread things out more, and if it will have any effect - put MAIN and DEV actions at different days/dates and/or time.

Document this in a table easily available in all documentation, to make this easily available.

If this cannot be solved, then I believe that automatic actions should be dropped, as they now create more problems and noise than what they solve.

[codebymini]

I think oddst's comment about spreading the different open source apps to different days has a valid point. It does not necessarily have any impact on this specific PR, but could be considered for similar changes to Loop and Trio

[marionbarker]

This minimal change is accepted for now. Moving our weekly and monthly builds to happen only on a weekend is a good change.