sync-mailing-list-mirror: work around authorization problems

Authorization is hard. So hard, in fact, that it seems that (maybe
due to incorrect optimizations?) pushes to GitHub with an installation
access token that has _just_ been obtained sometimes fail with a 403,
even though it seems that a re-run "fixes" the problem.

The first instances of this problem was
https://github.com/gitgitgadget-workflows/gitgitgadget-workflows/actions/runs/17543752351/job/49820347084#step:6:11
on Sep 8, 2025, 9:52 AM GMT+2:

  Run git push ***github.com/$TARGET_GITHUB_REPOSITORY lore-$LORE_EPOCH
  remote: Permission to gitgitgadget/git-mailing-list-mirror.git denied to gitgitgadget[bot].
  fatal: unable to access 'https://github.com/gitgitgadget/git-mailing-list-mirror/': The requested URL returned error: 403
  Error: Process completed with exit code 128.

This happened relatively shortly after I had merged
#12 on
Sep 5, 2025, 7:55 AM GMT+2, and there were 30 such occurrences of
denied pushes due to apparently not-yet-valid installation tokens in
https://github.com/gitgitgadget-workflows/gitgitgadget-workflows/actions/workflows/sync-mailing-list-mirror.yml
(which isn't bad, given that there have been 1,892 runs of that workflow
since Sep 5, 8:44 AM GMT+2, as of time of writing).

So it _might_ seem as if the flake has something to do with this change,
but then, it occurs too rarely to be _caused_ by that change, _and_ it
seems to happen a tad more frequently than once a day _but_ started 3
days after merging that PR. As I stated above, I have come to the
conclusion that it is something on GitHub's side where they changed
something on their side that _sometimes_ lets installation access tokens
be _not quite ready for pushing_ for a little while right after the
tokens have been issued.

Corroborating evidence for that suspicion are the 8 occurrences of the
same issue in the sister repository I established for Cygwin:
https://github.com/cygwingitgadget/gitgitgadget-workflows/actions/workflows/sync-mailing-list-mirror.yml
And in that repository, essentially the same workflow had been running a
quite a few days longer _without_ any issues, more concretely, it has
done its job without problems since Aug 30, 2025, 6:40 PM GMT+2 in
https://github.com/cygwingitgadget/gitgitgadget-workflows/actions/runs/17346140096
until it failed for the first time on Sep 22, 2025, 7:24 PM GMT+2 in
https://github.com/cygwingitgadget/gitgitgadget-workflows/actions/runs/17923242729/job/50963073473#step:6:11
with the same 403.

Let's just work around that by trying again to push, if necessary a
couple of times (with a back-off strategy).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Author: dscho

.github/workflows/sync-mailing-list-mirror.yml

@@ -51,4 +51,19 @@ jobs:
       env:
         GITHUB_TOKEN: ${{ steps.token.outputs.token }}
       run: |
-        git push https://$GITHUB_ACTOR:$GITHUB_TOKEN@github.com/$TARGET_GITHUB_REPOSITORY lore-$LORE_EPOCH
+        backoff=0
+        while (
+          git push https://$GITHUB_ACTOR:$GITHUB_TOKEN@github.com/$TARGET_GITHUB_REPOSITORY lore-$LORE_EPOCH;
+          echo $? >exit.code
+        ) 2>&1 | tee output.log; exit_code="$(cat exit.code)"; test 0 != "$exit_code" && grep 403 output.log
+        do
+          backoff=$(($backoff+1))
+          test 10 -gt $backoff || {
+            echo '::error::Failed too many times' >&2
+            exit $exit_code
+          }
+          printf '::warning::access token somehow not yet active; sleeping for %d seconds\nexit code: %s\n' \
+            $backoff $(cat exit.code)
+          sleep $backoff
+        done
+        exit $exit_code