Staging universe freezes and timing

[wlandau]

@shikokuchuo, this PR implements freezing in update_staging(): packages already in Staging are frozen if they don't have an issue file. Also, I added a staging_is_active() function to determine when the staging universe should be active. If each staging period is 30 days, I thought the start dates c("01-15", "04-15", "07-15", "10-15") would nicely avoid major holidays, but please let me know if different choices would be better.

After this PR, I was thinking we could merge all the GitHub Actions workflows for https://github.com/r-multiverse/staging into a single workflow that does the following:

1. Check staging_is_active(). If FALSE, stop the workflow immediately and skip all the following steps.
2. Record check issues in Staging (record_issues())
3. Update Staging's packages.json (update_staging())
4. Push changes back to https://github.com/r-multiverse/staging.

Because of (1), Staging will automatically stop updating after the 30-day period. At that point, we have time to create and troubleshoot the Production snapshot. After we're sure the snapshot succeeded, we could create a GitHub release to tag the state of Staging at the snapshot, then manually delete https://github.com/r-multiverse/staging/blob/main/packages.json to get Staging ready for next quarter's round of updates. Does that sound like a reasonable plan? I think it gives us leeway in case something initially goes wrong with Production, and the manual steps are easy.

[shikokuchuo]

Thanks Will, I will look through this.

Because of (1), Staging will automatically stop updating after the 30-day period. At that point, we have time to create and troubleshoot the Production snapshot. After we're sure the snapshot succeeded, we could create a GitHub release to tag the state of Staging at the snapshot, then manually delete https://github.com/r-multiverse/staging/blob/main/packages.json to get Staging ready for next quarter's round of updates.

Sounds about right. I may open another PR to put in some functions that make the release and snapshot (if it's feasible). That way we can document as much as possible, so although it won't run on a cron job there is little ambiguity about how releases are made.

[shikokuchuo]

If each staging period is 30 days, I thought the start dates c("01-15", "04-15", "07-15", "10-15") would nicely avoid major holidays, but please let me know if different choices would be better.

I like the proposed dates. I've opened a PR to this PR to change to calendar months rather than 30 days, which should be easier to understand.

[shikokuchuo]

Looks good. If you merge my PR which targets yours, I'll then approve this.

[wlandau]

I merged your changes into my branch, with the extra restriction that we choose thresholds earlier than day 28 in the month (to avoid complications from months with different durations).