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

NEW
Unassigned

Status

Release Engineering
General Automation
2 years ago
2 years ago

People

(Reporter: gps, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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.