view doc/README @ 52156:8766d47edfd1 stable

ci: add a runner for Windows 10

This is currently only manually invoked, and allows for failure because we only
have a single runner that takes over 2h for a full run, and there are a handful
of flakey tests, plus 3 known failing tests.

The system being used here is running MSYS, Python, Visual Studio, etc, as
installed by `install-windows-dependencies.ps1`.  This script installs
everything to a specific directory instead of using the defaults, so we adjust
the MinGW shell path to compensate.  Additionally, the script doesn't install
the launcher `py.exe`.  It is possible to adjust the script to install it, but
it's an option to an existing python install (instead of a standalone installer),
and I've had the whole python install fail and rollback when requested to install
the launcher if it detects a newer one is already installed.  In short, it is
a point of failure for a feature we don't (yet?) need.

Unlike other systems where the intepreter name includes the version, everything
here is `python.exe`, so they can't all exist on `PATH` and let the script
choose the desired one.  (The `py.exe` launcher would accomplish, using the
registry instead of `PATH`, but that wouldn't allow for venv installs.)  Because
of this, switch to the absolute path of the python interpreter to be used (in
this case a venv created from the py39 install, which is old, but what both
pyoxidizer and TortoiseHg currently use).

The `RUNTEST_ARGS` hardcodes `-j8` because this system has 4 cores, and
therefore runs 4 parallel tests by default.  However on Windows, using more
parallel tests than cores results in better performance for whatever reason.  I
don't have an optimal value yet (ideally the runner itself can make the
adjustment on Windows), but this results in saving ~15m on a full run that
otherwise takes ~2.5h.  I'm also not concerned about how it would affect other
Windows machines, because we don't have any at this point, and I have no idea
when we can get more.

As far as system setup goes, the CI is run by a dedicated user that lacks admin
rights.  The install script was run by an admin user, and then the standard user
was configured to use it.  If I set this up again, I'd probably give the
dedicated user admin rights to run the install script, and reset to standard
user rights when done.  The python intepreter failed in weird ways when run by
the standard user until it was manually reinstalled by the standard user:

    Fatal Python error: init_fs_encoding: failed to get the Python codec of the
        filesystem encoding

Additionally, changing the environment through the Windows UI prompts to
escalate to an admin user, and then setting the user level environment variables
like `TEMP` and `PATH` (to try to avoid exceeding the 260 character path limit)
didn't actually change the user's environment.  (Likely it changed the admin
user's environment, but I didn't confirm that.)  I ended up having to use the
registry editor for the standard user to make those changes.

Mercurial's documentation is kept in reStructuredText format, which is
a simple plain text format that's easy to read and edit:

  http://docutils.sourceforge.net/rst.html

It's also convertible to a variety of other formats including standard
UNIX man page format and HTML. You'll need to install Docutils:

  http://docutils.sourceforge.net/

Use the Makefile in this directory to generate the man and HTML pages.