Adjust the schedule of the update-git-version-and-manual-pages workflow

Currently, the `update-git-version-and-manual-pages` workflow is
scheduled to run at 17:37:00 UTC every day. Naturally, it's never that
precise, it usually takes about four minutes for the workflow run to
start.

In reaction to being asked how quickly https://git-scm.com/docs/ is
updated after a new Git version is released, I had a look and it seems
as if this schedule (which I had made up from thin air, lacking anything
else to base it on) is misaligned just enough that it would have missed
virtually every single recent releases, but not by much, hence being
maximally late to the game whenever a new Git version is available.

There is sadly no consistency in the times when Git versions are
released (unlike projects like, say, cURL, which have highly consistent
and clearly documented and very well communicated release cycles, see
https://daniel.haxx.se/blog/2022/08/16/the-curl-release-cycle/ for more
on this), but we can still try to recognize whatever traces of patterns
might exist to indicate a better time when that workflow should run.

To do so, let's have a look at the activity (which can be seen on GitHub
at https://github.com/git/git/activity?ref=master, even if there is
unfortunately no way to see the activity for tags; This information
seems simply never to be recorded, but we can hope that the `master`
updates coincide with the tag updates).

My first attempt to extract these times using the regular REST API, i.e.
https://docs.github.com/en/rest/activity/events?apiVersion=2022-11-28#list-public-organization-events,
failed miserably, _immediately_ running into a 422 "In order to keep the
API fast for everyone, pagination is limited for this resource.". The
reason is that the REST API, unlike the web UI, offers no option to
filter by event type, let alone by branch name, and hence I had to
ingest _all of the events_ only to filter out most of them.

So what is a researcher supposed to do in such a situtation? Well, there
is always the option to cobble something together in Web Developer
Tools. So that's what I did, running the following Javascript snippet on
above-mentioned https://github.com/git/git/activity?ref=master page,
then "turning the page", run it again, lather, rinse, repeat:

  [
    ...document
      // among the many, _many_ nested <div>s, look for a long list
      .querySelector('div:has(> :last-child:nth-child(30))')
      .children
  ].map(e => {
    return {
      message: e.firstChild.querySelector(':not(:empty)').innerText,
      date: e.querySelector('span[title]').getAttribute('title')
    }
  }).filter(e =>
    !e.message.match(
      // Yes, the commit titles vary wildly
      /(^(Merge |A (bit|few) more |Sync with 'maint'|Hopefully|Clean|Mostly|Start|Prepare)|updates|batch|touches|typo|wording)/
    )
  ).map(e =>
    // turn the date into an ISO string for easier sorting and alignment
    `| ${(new Date(e.date)).toISOString()} | ${e.message} |`
  ).join('\n')

Yes, this is horrible, and I would much prefer not having to write hacks
like that. In any case, as of time of writing, the result is this:

| 2025-03-10T16:46:00.000Z | Git 2.49-rc2 |
| 2025-03-04T17:11:00.000Z | Git 2.49-rc1 |
| 2025-02-26T18:02:00.000Z | Git 2.49-rc0 |
| 2025-01-14T17:58:00.000Z | Sync with Git 2.48.1 |
| 2025-01-10T18:10:00.000Z | Git 2.48 |
| 2025-01-06T18:45:00.000Z | Git 2.48-rc2 |
| 2024-12-30T17:10:00.000Z | Git 2.48-rc1 |
| 2024-12-16T17:42:00.000Z | Git 2.48-rc0 |
| 2024-11-25T05:57:00.000Z | Sync with Git 2.47.1 |
| 2024-10-07T15:04:00.000Z | Git 2.47 |
| 2024-10-02T16:49:00.000Z | Git 2.47-rc1 |
| 2024-09-26T16:38:00.000Z | Git 2.47-rc0 |
| 2024-09-14T16:13:00.000Z | Sync with Git 2.46.1 |
| 2024-07-29T16:58:00.000Z | Git 2.46 |
| 2024-07-24T17:01:00.000Z | Git 2.46-rc2 |
| 2024-07-18T16:54:00.000Z | Git 2.46-rc1 |
| 2024-07-12T16:51:00.000Z | Git 2.46-rc0 |
| 2024-05-31T17:21:00.000Z | Sync with Git 2.45.2 |
| 2024-05-14T16:57:00.000Z | Sync with Git 2.45.1 |
| 2024-04-29T16:59:00.000Z | Git 2.45 |
| 2024-04-24T16:53:00.000Z | Git 2.45-rc1 |
| 2024-04-19T16:51:00.000Z | Git 2.45-rc0 |
| 2024-02-23T17:01:00.000Z | Git 2.44 |
| 2024-02-20T17:02:00.000Z | Git 2.44-rc2 |
| 2024-02-14T16:59:00.000Z | Git 2.44-rc1 |
| 2024-02-09T17:05:00.000Z | Git 2.44-rc0 |
| 2023-11-20T17:00:00.000Z | Git 2.43 |
| 2023-11-14T17:11:00.000Z | Git 2.43-rc2 |
| 2023-11-08T17:06:00.000Z | Git 2.43-rc1 |
| 2023-11-02T17:01:00.000Z | Git 2.43-rc0 |
| 2023-08-21T17:33:00.000Z | Git 2.42 |
| 2023-08-15T20:06:00.000Z | Git 2.42-rc2 |
| 2023-08-10T16:09:00.000Z | Git 2.42-rc1 |
| 2023-08-04T19:05:00.000Z | Git 2.42-rc0 |
| ... | ... |

The time of day at which these pushes happened was apparently kind of
chaotic right up until November 2023, when they entered a period of
relative calm consistency where they meandered closely around 17:00:00
UTC. This changed mid-September 2024, when they became more erratic
again.

Now, as can be seen by the author date of 9d9fe75 (Add a workflow to
update the Git version and manual pages, 2023-10-10), I started
implementing the scheduled workflow in October 2023. However, as the
committer date reveals, the final form was reached only on Fri Sep 20
16:25:25 2024 +0200.

I probably had a look at only a couple of those push times when I
decided on the final schedule, at which time 17:37:00 UTC seemed like a
robust choice, and in hindsight I think I applied Occam's Razor
correctly, only to be ridiculed by reality afterwards.

For the record, the "37" was chosen in the spirit so delightfully
illustrated in https://xkcd.com/221/, although it wasn't fair, and I did
not use a die, let alone dice.

Now, as the evidence I provided above proves, that choice no longer
makes much sense and needs to be adjusted, and I am not talking about
the 37, I am talking about the 17.

Therefore, in the interest of picking up new Git versions reasonably
quickly, yet still using a fixed cron schedule (as opposed to insane
strategies such as running every five minutes, or adjusting the schedule
via another scheduled workflow that would analyze the push activity in
git/git and determine an update by using AI), let's settle on simply
running 2h later in the day.

Signed-off-by: Johannes Schindelin <[email protected]>

Author: dscho

.github/workflows/update-git-version-and-manual-pages.yml

@@ -9,7 +9,7 @@ on:
         default: false
   schedule:
     # check daily for updates
-    - cron: '37 17 * * *'
+    - cron: '37 19 * * *'
 
 jobs:
   update-git-version-and-manual-pages: