Trac #29534: Trigger CI workflows on GitHub Actions by pushing tags

1. If a developers wants to run the standard set of CI tests, just
pushing a tag is a simpler interface than creating a pull request:  `git
tag -f "ci" && git push --force github "ci"`

2. Also this ensures that releases always trigger a CI test.

Follow-up (wishlist): #29535 Customize CI workflows on !GitHub Actions
using specially structured tag names

URL: https://trac.sagemath.org/29534
Reported by: mkoeppe
Ticket author(s): Matthias Koeppe
Reviewer(s): Dima Pasechnik

Author: Release Manager

.github/workflows/ci-cygwin.yml

@@ -3,6 +3,9 @@ name: windows-latest
 on:
   pull_request:
     types: [opened, synchronize]
+  push:
+    tags:
+      - '*'
 
 env:
   MAKE: make -j8

.github/workflows/tox-optional.yml

@@ -20,6 +20,9 @@ name: Run SAGE_ROOT/tox.ini TARGETS_OPTIONAL
 on:
   pull_request:
     types: [opened, synchronize]
+  push:
+    tags:
+      - '*'
 
 env:
   TARGETS_PRE: build/make/Makefile

.github/workflows/tox.yml

@@ -20,6 +20,9 @@ name: Run SAGE_ROOT/tox.ini
 on:
   pull_request:
     types: [opened, synchronize]
+  push:
+    tags:
+      - '*'
 
 env:
   TARGETS_PRE: sagelib-build-deps

src/doc/en/developer/portability_testing.rst

@@ -916,7 +916,8 @@ Automatic parallel tox runs on GitHub Actions
 
 The Sage source tree includes a default configuration for GitHub
 Actions that runs tox on a multitude of platforms on every pull
-request to a repository for which GitHub Actions are enabled.
+request and on every push of a tag (but not of a branch) to a
+repository for which GitHub Actions are enabled.
 
 This is defined in the file ``$SAGE_ROOT/.github/workflows/tox.yml``.
 
@@ -936,8 +937,29 @@ workflow have finished.  Each job generates one tarball.
 "Annotations" highlight certain top-level errors or warnings issued
 during the build.
 
-The following procedure seems to work well for testing branches during
-development:
+The following procedure triggers a run of tests with the default set of
+system configurations.  Let's assume that ``github`` is the name of
+the remote corresponding to your GitHub fork of the Sage repository::
+
+  $ git remote -v | grep /my-github
+  my-github      https://github.com/mkoeppe/sage.git (fetch)
+  my-github      https://github.com/mkoeppe/sage.git (push)
+
+- Create a ("lightweight", not "annotated") tag with an arbitrary
+  name, say ``ci`` (for "Continuous Integration")::
+
+    git tag -f ci
+
+- Then push the tag to your GitHub repository::
+
+    git push -f my-github ci
+
+(In both commands, the "force" option (``-f``) allows overwriting a
+previous tag of that name.)
+
+For testing branches against a custom set of system configurations
+during development, the following procedure seems to work well.  It
+avoids changing the CI configuration on your development branch:
 
 - Create a branch from a recent beta release that contains the default
   GitHub Actions configuration; name it ``TESTER``, say.
@@ -951,6 +973,9 @@ development:
   pull request against the ``TESTER`` branch. This will trigger the
   GitHub Actions workflow.
 
+You will find a workflow status page in the "Actions" tab of your
+repository.
+
 Here is how to read it.  Each of the items in the left pane represents
 a full build of Sage on a particular system configuration.  A test
 item in the left pane is marked with a green checkmark in the left