• Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • None
    • Platform: All, OS: All

      See mailing list thread "Using Hudson in productive environment". Some builds
      need to do GUI tests and need a graphic display. Running Hudson with a test
      display is always possible, but cumbersome to set up, and limits you to one
      executor (otherwise tests can interfere with one another if they grab focus at
      the wrong time etc.). The suggestion is:

      1. Have a checkbox (off by default) in project config to run jobs in a dedicated
      display. Also have a pulldown for display type, including at least (according to
      availability):

      • VNC
      • X
      • Xnest

      2. If set, start a new display for the duration of a job run. For X11-based
      systems, set the DISPLAY environment variable. (I do not know if there is any
      equivalent for Windows servers, or for Mac OS X. But should work fine on Linux
      and other Unix variants.)

      3. In the case of VNC, a cute trick (license permitting?) would be to use

      http://www.realvnc.com/javavncviewer.html

      to show the live display on the job's page. My Fedora Core system has this as

      /usr/share/vnc/classes/vncviewer.jar

      which curiously is part of the 'vnc-server' RPM, not vnc; it seems to be a Java
      main class, not an applet, but this should be solvable (at worst by serving a
      .jnlp file for it). Maybe Maven has the right JAR somewhere.

          [JENKINS-158] Manage graphic displays for running jobs

          What I think we need is a kind of "build wrapper" — an extension point where
          the code could execute something before/after the build (regardless of the build
          result), and pass in perhaps environment variables to the actual build.

          It is used to set up something for the build, then tear it down later.

          This X server set up would fit into that abstraction nicely. At my deployment,
          we have a similar need to run Glassfish so that the "build" (which is really a
          test) would rely on.

          I don't think both X and Glassfish are not common enough that the feature should
          live in the core, but we need such an extension point in the core.

          Kohsuke Kawaguchi added a comment - What I think we need is a kind of "build wrapper" — an extension point where the code could execute something before/after the build (regardless of the build result), and pass in perhaps environment variables to the actual build. It is used to set up something for the build, then tear it down later. This X server set up would fit into that abstraction nicely. At my deployment, we have a similar need to run Glassfish so that the "build" (which is really a test) would rely on. I don't think both X and Glassfish are not common enough that the feature should live in the core, but we need such an extension point in the core.

          Jesse Glick added a comment -

          Well you can just switch the build command to be a shell script which does the
          pre- and post-steps. I just filed this issue because writing the shell script
          stuff to set up and tear down a temporary X server is not so trivial and I
          thought it would be helpful to have it built into Hudson. But if you think it's
          too rare, this can just be closed.

          Jesse Glick added a comment - Well you can just switch the build command to be a shell script which does the pre- and post-steps. I just filed this issue because writing the shell script stuff to set up and tear down a temporary X server is not so trivial and I thought it would be helpful to have it built into Hudson. But if you think it's too rare, this can just be closed.

          I think the individual application of setup/teardown phase is fairly specific,
          but the pattern of setup/teardown is very common.

          So I'd like to have a hook for that in Hudson, but leave the actual
          setup/teardown support to plugins.

          Kohsuke Kawaguchi added a comment - I think the individual application of setup/teardown phase is fairly specific, but the pattern of setup/teardown is very common. So I'd like to have a hook for that in Hudson, but leave the actual setup/teardown support to plugins.

          Jesse Glick added a comment -

          My point is that a generic hook is not terribly useful. You can already replace

          ant do-something

          with

          ./do-some-setup.sh; ant do-something; ./do-some-cleanup.sh

          That is trivial. Writing correct do-some-setup.sh and do-some-cleanup.sh scripts
          is the tricky part.

          Jesse Glick added a comment - My point is that a generic hook is not terribly useful. You can already replace ant do-something with ./do-some-setup.sh; ant do-something; ./do-some-cleanup.sh That is trivial. Writing correct do-some-setup.sh and do-some-cleanup.sh scripts is the tricky part.

          The hook is for plugins, not for users.
          So the end result for users would be one check box like this:

          [x] This project uses X display during a build

          Or in my case:

          [x] This project needs a running Glassfish instance

          ... which is more or less what you had in your mind, I think.
          Internally this should be built on top of a hook, so that
          other kinds of setup/teardown can be added.

          Kohsuke Kawaguchi added a comment - The hook is for plugins, not for users. So the end result for users would be one check box like this: [x] This project uses X display during a build Or in my case: [x] This project needs a running Glassfish instance ... which is more or less what you had in your mind, I think. Internally this should be built on top of a hook, so that other kinds of setup/teardown can be added.

          I put the initial work in the xvnc plugin.

          Any change to the plugin much appreciated.

          Kohsuke Kawaguchi added a comment - I put the initial work in the xvnc plugin. Any change to the plugin much appreciated.

          Jesse Glick added a comment -

          1. If you click the help button for the Xvnc config, you get a 404. Not sure
          where a plugin is supposed to put its HTML page exactly. Says it was trying
          /hudson/plugins/xnvc/help-something.html (don't remember exactly).

          2. Killing the vncserver process may not be wise; in fact it may not work at
          all, looking at the script. "vncserver -kill :$DISPLAY" is what you are supposed
          to do. You can directly kill the Xvnc process if you started it that way, I
          think. Could probably just call Xvnc directly; I don't see anything important
          (in this context) that the vncserver script does.

          3. If you really plan to release this don't forget to

          Index: plugins/pom.xml
          ===================================================================
          RCS file: /shared/data/ccvs/repository/hudson/hudson/plugins/pom.xml,v
          retrieving revision 1.9
          diff -u -r1.9 pom.xml
          — plugins/pom.xml 18 Nov 2006 18:43:09 -0000 1.9
          +++ plugins/pom.xml 20 Nov 2006 00:45:31 -0000
          @@ -61,5 +61,6 @@
          <module>jwsdp-sqe</module>
          <module>jprt</module>
          <module>promoted-builds</module>
          + <module>xvnc</module>
          </modules>
          </project>

          Jesse Glick added a comment - 1. If you click the help button for the Xvnc config, you get a 404. Not sure where a plugin is supposed to put its HTML page exactly. Says it was trying /hudson/plugins/xnvc/help-something.html (don't remember exactly). 2. Killing the vncserver process may not be wise; in fact it may not work at all, looking at the script. "vncserver -kill :$DISPLAY" is what you are supposed to do. You can directly kill the Xvnc process if you started it that way, I think. Could probably just call Xvnc directly; I don't see anything important (in this context) that the vncserver script does. 3. If you really plan to release this don't forget to Index: plugins/pom.xml =================================================================== RCS file: /shared/data/ccvs/repository/hudson/hudson/plugins/pom.xml,v retrieving revision 1.9 diff -u -r1.9 pom.xml — plugins/pom.xml 18 Nov 2006 18:43:09 -0000 1.9 +++ plugins/pom.xml 20 Nov 2006 00:45:31 -0000 @@ -61,5 +61,6 @@ <module>jwsdp-sqe</module> <module>jprt</module> <module>promoted-builds</module> + <module>xvnc</module> </modules> </project>

          Thanks. I couldn't reproduce 404 problem — maybe there's some kind of a
          packaging bug that cannot be reproduced with "hpi:run"? I'll check in my
          production environment.

          I read vncserver man page and I thought it said "vncserver -kill" would really
          just kill the process, and the only extra it does is the automatic discovery of
          the process ID. I thought it's bit silly to launch another process just to kill
          it, when I already know what that process is. But I should probably check it anyway.

          Thanks for the <modules> change. I forgot that.

          I'll mark this issue fixed for now. Further issues to the xvnc plugin should
          deserve their own issue numbers.

          Kohsuke Kawaguchi added a comment - Thanks. I couldn't reproduce 404 problem — maybe there's some kind of a packaging bug that cannot be reproduced with "hpi:run"? I'll check in my production environment. I read vncserver man page and I thought it said "vncserver -kill" would really just kill the process, and the only extra it does is the automatic discovery of the process ID. I thought it's bit silly to launch another process just to kill it, when I already know what that process is. But I should probably check it anyway. Thanks for the <modules> change. I forgot that. I'll mark this issue fixed for now. Further issues to the xvnc plugin should deserve their own issue numbers.

            Unassigned Unassigned
            jglick Jesse Glick
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: