Closed Bug 393410 Opened 14 years ago Closed 13 years ago
reftest should be able to create a (temporary) profile with appropriate prefs
4.70 KB, patch
|Details | Diff | Splinter Review|
3.12 KB, text/plain
16.75 KB, patch
|Details | Diff | Splinter Review|
Summary: reftest profile creation → reftest should be able to create a (temporary) profile with appropriate prefs
I have a perl script that does this for me now. Let me know if you are interested in seeing it. If you already have yours done, no worries.
Sure, can't hurt. Paste it in as an attachment if you like and we can enpatchify it.
Here is the script I wrote. Issues with it are: - yo no hablo Windows! How can I make this more cross-platform? - extra cruftiness ends up in one's profile.ini file - any others?
robcee: you mentioned yesterday that one of the frameworks already did this (mochitest?) -> where can I find that script?
yep, that's the one. I'm not sure if we want to rip that out and include the profile creation as a separate perl script or write some buildsteps to produce the same thing in python buildbot code. Take your pick. :)
Well, this may be just an issue I have. If I look at two methods for constructing profile directories, ie: - using -createprofile, part of Firefox, in the way that FF probably uses it - using extra code to artificially reproduce what we think Firefox is doing I see the former as being significantly more useful to testing than the latter. Institutionally, as a group, the people more "in the community" than I seem to prefer the latter. I am not sure what to make of this. My approach often brings out architectural issues with the apps I work with, highlighting their fragilities. But then, I think that is the point. But the latter approach gets you something today. So, I guess, take your pick. :-)
Ray, tests need a special profile and most (if not all) of the mochitest's runtests.pl code creating the profile would still be needed even if it started with running firefox -createprofile.
I'd love it if runtests.pl were really a Python script (and perhaps if the basic running stuff were abstracted into some sort of class, probably as a followup -- just hacking a copy of it would be enough to start). Every time I have to touch that I curse myself for not rewriting it in Python the first time I touched it, back when it was a good bit smaller and somewhat more hackish.
I've actually started writing some of this as part of the bug 397724 (leak+reftest). robcee has a basic list above, but tinderbox also has a pretty complete list after many years: http://mxr.mozilla.org/seamonkey/source/tools/tinderbox/build-seamonkey-util.pl#2129 Please let me know if there are any others I should be including.
Status: NEW → ASSIGNED
Priority: P3 → P2
People seemed to be wanting a python version, so here it is. This will make it easier to fold it into buildbot sometime in the future. Not sure where this should live. We can add whatever MOZ_CO_MODULE we want to the mozconfigs, so we have some choices.
Attachment #290585 - Flags: review?(rcampbell)
Attachment #290585 - Attachment mime type: text/x-python → text/plain
When I create a profile with this, on an intel mac with 10.4.10, I get a problem with the launched executable. It is the same problem as: http://bugzilla.mozilla.org/show_bug.cgi?id=381283 errors from launching Firefox on Mac with wrong capitalization So, something is wrong with the chrome initialization here (AFAIK). Why do you require the executable as a parameter here? I can see that the contents of the profile may be dependent on the _version_ of the executable, but I can think of no reason that the profile must depend on the location of the executable. Have you tested on a Mac? How do you invoke it? Does NO_EM_RESTART=1 poison the soup?
Comment on attachment 290585 [details] python script for finding/creating a new firefox profile and populating relevant prefs for testing I am nitless. This looks like it should do the job.
Attachment #290585 - Flags: review?(rcampbell) → review+
(In reply to comment #12) > Why do you require the executable as a parameter here? I can see that the > contents of the profile may be dependent on the _version_ of the executable, > but I can think of no reason that the profile must depend on the location of > the executable. Many of these build machines can have many builds slaves (or tinderbox trees) on the same box, and hence multiple executables. The script works on Linux, and I have it working on Windows after a small patch. Testing Mac now.
Does this script need to create the profile in the default location? I think it would make sense to have _either_ a --profileName flag, and have it behave as it does now, or a --profileDir flag. If this flag is used, the profile would be created at the path given and the profile name would _not_ be added to the profile.ini file. Would you accept a patch for this?
(In reply to comment #15) > Does this script need to create the profile in the default location? The rest of the reftest/buildbot harness doesn't do anything fancy with the profiles, i.e. we don't supply the optional --profileName arg and just go with the default. > I think it would make sense to have _either_ a --profileName flag, and have it > behave as it does now, or a --profileDir flag. If this flag is used, the > profile would be created at the path given and the profile name would _not_ be > added to the profile.ini file. > > Would you accept a patch for this? Sure, I'll take a patch. We won't likely use the functionality for reftesting, but having the option won't hurt.
Checking in profiles/createTestingProfile.py; /cvsroot/mozilla/testing/tools/profiles/createTestingProfile.py,v <-- createTestingProfile.py initial revision: 1.1 done
Changes are currently baking in the staging environment. This required changes to: * master.cfg -> replaced sqllite removal steps with createProfile* calls; * mozbuild.py -> addition of createProfile* classes; and, * mozconfig files -> needed to add MOZ_CO_MODULE="mozilla/testing/tools" to grab profile creation script from CVS
This is a patch against the current production master.cfg et al., and as such also contains lines to disable winxp and leopard.
Attachment #307724 - Flags: review?
Attachment #307724 - Flags: review? → review?(rcampbell)
Comment on attachment 307724 [details] [diff] [review] (re)create profiles on slaves for each run rather than culling places.sqlite [checked in] one nit: change class-names "createProfile(Win)" to "CreateProfile(Win)" to be consistent with class-naming conventions. Otherwise looks great!
Attachment #307724 - Flags: review?(rcampbell) → review+
Comment on attachment 307724 [details] [diff] [review] (re)create profiles on slaves for each run rather than culling places.sqlite [checked in] Nits fixed.
Attachment #307724 - Attachment description: (re)create profiles on slaves for each run rather than culling places.sqlite → (re)create profiles on slaves for each run rather than culling places.sqlite [checked in]
Pushed to production. Monitoring.
Unrelated Win2K3 bustage, but otherwise looks good.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Component: Testing → Release Engineering
Product: Core → mozilla.org
QA Contact: testing → release
Version: unspecified → other
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.