[Buildbot-commits] [Buildbot] #971: Build a windows installer

[Buildbot]

#971: Build a windows installer
------------------------+-----------------------
Reporter:  dustin       |       Owner:  fatman2
    Type:  enhancement  |      Status:  accepted
Priority:  major        |   Milestone:  0.8.+
 Version:               |  Resolution:
Keywords:  windows      |
------------------------+-----------------------

Comment (by jollyroger):

 Replying to [comment:24 fatman2]:
 > I intended this to be a monolithic installer that would take the user
 from "no Buildbot installed" to "functional Buildbot up and running" as
 quickly as possible. Some parts of the install are painful even for an
 experienced Windows user and sysadmin, and it's easy to go wrong and not
 know why. In my opinion, the whole thing can and should be automated.

 I'd like to propose some different alternative for this. What if we just
 leave just the installation and dependencies to the installer and run some
 "New buildbot instance" wizard right after the installation as some
 software under windows does (some antiviruses or software that needs to be
 configured anyway before it begins to work correctly). Also, this would be
 a common task, so there should be a link for it in "menu" group.

 > > hardcoded paths ... and some install paths in "Program Files"
 >
 > Yes, I don't like this either. I was intending to remove the hardcoded
 paths after I got the installer basically working. The "Program Files"
 problem isn't easy to solve because Windows has no single standard
 location for user programs like other operating systems do.

 Anyway every Python environment will write its $PYTHONDIR/Scripts into the
 $PATH variable. Futhermore, there is a common structure for binary
 distributions of Python modules (including buildbot). Look into "Compile-
 time preparations" section in my source code. The main idea there is to
 ask Python generate binary distribution, extract it to NSIS build
 directory and remove precompiled *.pyc (they would be generated again on a
 target box anyway for every Python installer where buildbot would be
 installed to). My code also generates installer in form
 "buildbot-$VERSION.exe".

 > > cmake ... Isn't this too much (adding new unnecessary build
 dependency)?
 >
 > There's no dependency. The Fossil repository is just an image of my own
 working directory. The NSIS scripts are the important thing. They don't
 depend on CMake at all. I happen to use CMake because I like it, but if
 you don't, then feel free to delete CMakeLists.txt and the cmake dir.
 Nothing bad will happen.

 I'm aware of this. I was at fist confused with build problems and thought
 that CMake infrastructure has something to do with this. But it happened
 that your CMakeLists.txt required cl.exe just to generate makefiles so I
 downloaded (in addition to cmake) express edition of Visual studio just to
 assure that I'm not doing anything wrong(though I should have looked into
 the CMakeLists.txt itself at first). That was not a good start and I think
 anyone willing to look on windows installer will in the end be much
 confused with this much of unneeded code and software required just to
 build an installer.

 > > I would leave an installer only two functions:
 > It certainly makes sense from a purist angle, but the problem is that
 Buildbot isn't an ordinary program. There are a lot of fiddly little tasks
 that need doing (set up a user, log on as that user, set up service, log
 out, etc) that could be done so much more easily with a script.

 See my thoughts on the wizard above.

 > > other actions may be done more than once ... separate commands in
 "buildbot" menu
 > Good point. A simple installer can't take care of this. I suggest we
 need an administration program to take care of each "slave herd", but
 until we sort that out your menu icons might be the best way to go. The
 installer should install only one master or only one slave (or only one of
 each), plus your admin icons to add/delete slaves, etc. Does it make sense
 to have more than one master per machine? Yes, I think so.

 Again, the wizard should solve this. On this stage you'll have already
 installed buildbot code (with no instances) and are in the process of
 creating a new instance. Even if you cancel this operation, this won't
 affect the installer since it has already exited. But you'll be able to
 run the operation again from the menu group.

 > > Creating users, registering services ... tools installed together with
 buildbot or by hand
 > Disagree very much for reasons stated above.
 Again, this should not be a part of the installer but some wizard.

 > >  * Installer should be able to install buildbot for Python 2.x branch
 >= 2.4
 > Eeek! Have you tried this? Agreed it needs to be done. Stupid twisty
 Python. :P

 See my code and maybe try my installer, I've already implemented
 installing buildbot to different installed Python versions at once.
 However this will be reworked to add dependencies subsections for each
 Python distribution.

 > > I propose the following installer workflow:
 > >  4. Creating links and menu groups. Currently didn't go far into
 details.
 >
 > I suggest links for creating and destroying herds of masters and slaves.
 The problem is that we can make Buildbot menu group overbloated with lots
 of options because there are lots of parameters to vary. I suggest to have
 "New master wizard" and "Uninstall master" menu options in the root of
 buildbot menu group together with "instances" directory. Each directory
 would have subdirectory in form "<bot name> (Python <PYTHONVERSION>)" with
 links to start, stop and remove bot (and maybe additional
 option:configure, if someone will write a gui someday, but this is a kind
 of silly).

 > > Another question to discuss is the uninstaller. It is surely will be
 written, but I have doubts about where it should be located. Since we
 could install buildbot into several places at once, the uninstaller should
 have some common place or else we should generate uninstaller for every
 Python environment. The uninstaller's behavior is an open question though.
 Should it remove all installed files from all environments at once or just
 remove buildbot code from the corresponding Python environment? Ideas are
 welcome.
 >
 > Oh boy. This is a biggy. I have several opinions on this, all
 conflicting. More discussion needed.
 Here what I'm thinking about this. Buildbot installs all its code inside
 the Python environment. This means we don't need an extra directory in
 Program Files. However there is only uninstaller that has nothing to go.
 It would be wrong to put uninstaller only in one Python environment,
 because all other Python environments are neither worse nor better.

 I mentioned two ways of uninstaller's logic: remove the buildbot code just
 from current Python environment or remove it at all. However, when I think
 about it, this may require to have lots of menu groups like "Buildbot for
 Python 2.4/2.5/2.6/2.7" or relative subgroups in general "Buildbot" menu
 which is not very great too.

 If we can write additional uninstaller page to give a possibility to
 remove buildbot code from desired Python environments, this would be uber
 great.

 NSIS can generate lots of equal uninstallers and I checked that already.
 All is left to do is to store install options to register during
 installation, read them during uninstall process, remove the buildbot code
 and all uninstallers that left behind.

-- 
Ticket URL: <http://trac.buildbot.net/ticket/971#comment:25>
Buildbot <http://buildbot.net/>
Buildbot: build/test automation