Changes between Version 5 and Version 6 of CygwinShellCommands


Ignore:
Timestamp:
Jan 4, 2017, 2:01:22 AM (2 years ago)
Author:
rutsky
Comment:

update "slave" with "worker"

Legend:

Unmodified
Added
Removed
Modified
  • CygwinShellCommands

    v5 v6  
    11This is just to share a technique that I thought turned out rather well. Hope it helps.
    22
    3 This method allowed me to use the same complex buildsteps (!ShellCommands) I originally developed for Linux buildslaves, on Windows buildslaves also- without having to change very much.  Cygwin emulates Linux very well for bash scripting and file handling, including fetching source code.  When needed, however, you can still run something (a make tool, for example) in a "pure" Windows environment. 
     3This method allowed me to use the same complex buildsteps (!ShellCommands) I originally developed for Linux workers, on Windows workers also- without having to change very much.  Cygwin emulates Linux very well for bash scripting and file handling, including fetching source code.  When needed, however, you can still run something (a make tool, for example) in a "pure" Windows environment. 
    44
    5 You do NOT need to start your Windows buildslave from Cygwin.
     5You do NOT need to start your Windows worker from Cygwin.
    66
    7 Finally, you do not need to maintain a large library of pre-installed script files on every buildslave, or checked-in alongside the project source code.  Almost all the "scripts" buildbot uses are maintained within the buildbot configuration itself.  There are structural drawbacks to this approach, and someday I will refactor my buildbot configuration to maintain much more implementation detail alongside the project source code.  However, this approach has worked very well for rapid development of new buildbot functionality.
     7Finally, you do not need to maintain a large library of pre-installed script files on every worker, or checked-in alongside the project source code.  Almost all the "scripts" buildbot uses are maintained within the buildbot configuration itself.  There are structural drawbacks to this approach, and someday I will refactor my buildbot configuration to maintain much more implementation detail alongside the project source code.  However, this approach has worked very well for rapid development of new buildbot functionality.
    88
    99Example:
     
    4141 * For builds to run on Windows,
    4242{{{
    43     bash = r'C:cygwin-1.7inash.exe'
     43    bash = r'C:cygwin-1.7inash.exe'
    4444}}}
    45   * Specifying the full Windows path to bash.exe (including the ".exe"), allows !ShellCommand to bypass cmd.exe and just run bash.exe directly. If your buildslave uses cmd.exe to run command(s), then you cannot pass a multiple-line command string.
     45  * Specifying the full Windows path to bash.exe (including the ".exe"), allows !ShellCommand to bypass cmd.exe and just run bash.exe directly. If your worker uses cmd.exe to run command(s), then you cannot pass a multiple-line command string.
    4646
    4747* The {{{envd}}} Python variable is a dictionary that defines environment variables for the !ShellCommand build step.
    4848
    49 * The {{{setenv.sh}}} file must be pre-installed on ALL buildslaves.  It defines any host-specific environment variables, as needed.
     49* The {{{setenv.sh}}} file must be pre-installed on ALL workers.  It defines any host-specific environment variables, as needed.
    5050
    51 * When something on the Windows buildslave needs to run in a "pure" Windows environment (no Cygwin influence), I can still start it from Cygwin- for example, see the commandline starting with "cmd /C" in the above. 
    52  * The {{{setenv.bat}}} file must be pre-installed on all Windows buildslaves.  It restores critical environment variables like PATH to the original Windows settings.  It can also remove environment variables defined by Cygwin, and make any other environment changes needed for the build.  Note that environment variable names in Windows are case-insensitive.
     51* When something on the Windows worker needs to run in a "pure" Windows environment (no Cygwin influence), I can still start it from Cygwin- for example, see the commandline starting with "cmd /C" in the above. 
     52 * The {{{setenv.bat}}} file must be pre-installed on all Windows workers.  It restores critical environment variables like PATH to the original Windows settings.  It can also remove environment variables defined by Cygwin, and make any other environment changes needed for the build.  Note that environment variable names in Windows are case-insensitive.
    5353 * It turned out that only a few individual build step commands ever needed this "cmd /C" treatment on Windows, at least in my case. Cygwin works well most of the time.
    5454
    5555* These multiple-line command strings can be much, much longer than the above example. 
    5656
    57 * Finally, as of buildbot 0.8.2 you must hack one python file in the Windows buildslave code, as shown below.  Without this change, bash cannot get a Linux-style pwd- it gets a Windows path instead, and your scripts break down.  See buildbot bug #456 for more info.
     57* Finally, as of buildbot 0.8.2 you must hack one python file in the Windows worker code, as shown below.  Without this change, bash cannot get a Linux-style pwd- it gets a Windows path instead, and your scripts break down.  See buildbot bug #456 for more info.
    5858{{{
    5959Left file: runprocess.py.prev