This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Should AppVeyor run compile Python in debug mode?
Type: Stage: resolved
Components: Build Versions: Python 3.8
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: pablogsal, terry.reedy, vstinner, zach.ware
Priority: normal Keywords:

Created on 2019-03-06 17:16 by vstinner, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (3)
msg337335 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-03-06 17:16
The Windows buildbots have been broken by PR 12073. Problem: AppVeyor didn't catch the bug before the change has been merged. Why? Because AppVeyor builds Python in release mode, whereas Windows buildbots build Python in debug mode.

https://bugs.python.org/issue36139#msg337320

IMHO AppVeyor should also build Python in debug mode to catch most bugs.

We should compare build time in debug mode and in release mode to see the cost of debug mode.

---

Somehow related issue: AppVeyor and Travis CI tests passed on PR 10497 "bpo-35224: PEP 572 Implementation" but buildbots failed. The problem is that buildbots pass "-u all" to "python -m test", whereas pre-commit CIs use "-uall,-cpu" (.travis.yml) or "-uall -u-cpu -u-largefile" (.github/appveyor.yml).

https://github.com/python/cpython/pull/10497#issuecomment-457409029

---

It's a trade-off between preventing bugs and CI performance...
msg337551 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2019-03-09 01:33
Testing with installed release builds is about twice as fast.

f:\dev\37>python -m test -ugui -j14  # Debug 32-bit 3.7
...
0:03:51 [412/416] test_tarfile passed (56 sec 7 ms) -- running: test_multiprocessing_spawn (1 min 46 sec)
0:04:14 [413/416] test_weakref passed (37 sec 771 ms) -- running: test_multiprocessing_spawn (2 min 8 sec), test_venv (40 sec 188 ms), test_zipfile (31 sec 718 ms)
0:04:37 [414/416] test_zipfile passed (53 sec 631 ms) -- running: test_multiprocessing_spawn (2 min 31 sec), test_venv (1 min 3 sec)
0:04:43 [415/416] test_venv passed (1 min 8 sec) -- running: test_multiprocessing_spawn (2 min 37 sec)
running: test_multiprocessing_spawn (3 min 7 sec)
0:05:31 [416/416] test_multiprocessing_spawn passed (3 min 25 sec)

f:\dev\37>py -3.7 -m test -ugui -j14  # Installed 64-bit 3.7
...
0:01:53 [412/416/2] test_urllib2_localnet passed -- running: test_multiprocessing_spawn (53 sec 953 ms), test_socket (39 sec 298 ms)
0:01:55 [413/416/2] test_socket passed (40 sec 929 ms) -- running: test_multiprocessing_spawn (55 sec 953 ms)
0:01:56 [414/416/2] test_zipfile passed -- running: test_multiprocessing_spawn (57 sec 141 ms)
0:02:11 [415/416/2] test_venv passed (37 sec 543 ms) -- running: test_multiprocessing_spawn (1 min 12 sec)
0:02:37 [416/416/2] test_multiprocessing_spawn passed (1 min 37 sec)

My memory is that other things being equal, 32 bit should be faster than 64, but I presume you know more than I do.

Doubling CI time would be painful.  How often are buildbot failure due to the build or test-arg differences, as opposed to system differences?
msg338382 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-03-19 16:39
> Doubling CI time would be painful.  How often are buildbot failure due to the build or test-arg differences, as opposed to system differences?

Yeah, you're right. Such issue is really rare, so I'm ok to leave the pre-commit CI as it is ;-)
History
Date User Action Args
2022-04-11 14:59:12adminsetgithub: 80396
2019-03-19 16:39:58vstinnersetstatus: open -> closed
resolution: not a bug
messages: + msg338382

stage: resolved
2019-03-09 01:33:23terry.reedysetnosy: + terry.reedy
messages: + msg337551
2019-03-06 17:16:47vstinnercreate