( )⚙ D11025 ci-windows: introduce manual windows CI

This is an archive of the discontinued Mercurial Phabricator instance.

ci-windows: introduce manual windows CI
ClosedPublic

Authored by Alphare on Jul 8 2021, 11:53 AM.

Details

Summary

Note: most of the foundational work of this commit was done by Matt Harbison,
but enough has changed that I don't feel comfortable sending this patch as his.

In our quest to remove Python 2 from Mercurial, we need to get Windows CI going
to check that Python 3 support is up to an acceptable standard.
This is the first step: adding a manual step to run a full Windows CI, with a
certain definition of "full" since some things are not installed yet, like SVN.

Diff Detail

Repository
rHG Mercurial
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

Alphare created this revision.Jul 8 2021, 11:53 AM
baymax updated this revision to Diff 29031.Jul 8 2021, 7:59 PM

✅ refresh by Heptapod after a successful CI run (🐙 💚)

baymax updated this revision to Diff 29091.Jul 9 2021, 10:26 PM

✅ refresh by Heptapod after a successful CI run (🐙 💚)

baymax updated this revision to Diff 29112.Jul 10 2021, 12:09 PM

✅ refresh by Heptapod after a successful CI run (🐙 💚)

I assume the various things that I was installing in before_script are now baked into to the docker image/runner host? (That's good, it was my intention. But the TEMP variable hack made me wonder if maybe it wasn't yet.)

I'm also a bit surprised you haven't hit any issues by leaving out the make local bits.

contrib/heptapod-ci.yml
152–153

Do we also need to mkdir -p this?

172

What generates this file?

I assume the various things that I was installing in before_script are now baked into to the docker image/runner host? (That's good, it was my intention. But the TEMP variable hack made me wonder if maybe it wasn't yet.)

Yes they are.

I'm also a bit surprised you haven't hit any issues by leaving out the make local bits.

I don't know what error you were getting without --local, but the latest run are doing without it. I made a bunch of fixes to run-tests.py that might have helped (and there will be more)

I assume the various things that I was installing in before_script are now baked into to the docker image/runner host? (That's good, it was my intention. But the TEMP variable hack made me wonder if maybe it wasn't yet.)

Yes they are.

I'm also a bit surprised you haven't hit any issues by leaving out the make local bits.

I don't know what error you were getting without --local, but the latest run are doing without it. I made a bunch of fixes to run-tests.py that might have helped (and there will be more)

IDR at this point, but it was scattered throughout the tests. I thought maybe it was not building the C extensions and falling back to pure, and having some differing output.

On a related note, it might be good if we have some way to lock in using cext on Windows (assuming we don't want the overhead of also running pure tests there too). I'm not sure why anyone would use pure there since there are binary installers, and we had a nasty bug in pure relating to corrupting the manifest with a bunch of file removes in 4.7-4.9 or so. I guess there was a bug in the installer that caused it to not load cext, and that's how it was triggered on Windows in the field. But that shouldn't block this.

This revision was not accepted when it landed; it landed in state Needs Review.
This revision was automatically updated to reflect the committed changes.

On a related note, it might be good if we have some way to lock in using cext on Windows (assuming we don't want the overhead of also running pure tests there too).

We I guess we could lock the policy to "c" instead of "allow" on windows. Would you send a patch ?