If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

mozharness virtualenv directories aren't clobbered on Try



Release Engineering
General Automation
2 years ago
2 years ago


(Reporter: gps, Unassigned)


Firefox Tracking Flags

(Not tracked)




2 years ago
From https://archive.mozilla.org/pub/firefox/try-builds/gszorc@mozilla.com-c8d7b322ba0b7f1b0c66e6037ffe0eda2dc8c7c7/try-macosx64/try-macosx64-bm83-try1-build17126.txt.gz

15:54:55     INFO - Creating virtualenv /builds/slave/try-m64-0000000000000000000000/build/venv
15:54:55     INFO - virtualenv script: /builds/slave/try-m64-0000000000000000000000/scripts/virtualenv/virtualenv.py
15:54:55     INFO - Virtualenv /builds/slave/try-m64-0000000000000000000000/build/venv appears to already exist; skipping virtualenv creation.

It surprised me that the virtualenv directory existed on a try push: try jobs are supposed to start with empty state.

I performed a subsequent Try push where I performed a os.walk() on the virtualenv directory and sure enough, I saw a populated virtualenv, complete with requests and a few other Python packages.

From IRC:

16:11 < gps> shouldn't try builds have empty state?
17:00 < aki> they should, but i don't think they're clobbered in mh clobber, so it expects runner or something external to nuke it
17:00 < aki> unless the venv is created under the work_dir, in which case it'll be clobbered along with work_dir
17:24 < gps> aki: thanks. i'll file a bug.
17:25 < aki> for try it might be easiest to move the venv into the work_dir, not sure how hard it is to get try runner to nuke venv

I agree with aki: the virtualenv should be part of the working directory.
You need to log in before you can comment on or make changes to this bug.