After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 348487 - DBus frontend for JHBuild
DBus frontend for JHBuild
Status: RESOLVED OBSOLETE
Product: jhbuild
Classification: Infrastructure
Component: general
unspecified
Other All
: Normal enhancement
: ---
Assigned To: James Henstridge
Jhbuild QA
Depends on:
Blocks:
 
 
Reported: 2006-07-24 10:40 UTC by Jose Dapena Paz
Modified: 2008-06-22 19:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
This patch adds a dbus frontend to jhbuild. (19.26 KB, patch)
2006-07-24 11:32 UTC, Jose Dapena Paz
none Details | Review

Description Jose Dapena Paz 2006-07-24 10:40:23 UTC
It would be interesting to be able to implement a DBus service to control and handle builds using JHBuild.

Goals:
   * Be able to launch JHBuild as a DBus service.
   * Also test how can this be set it up with DBus activation.
   * Implement the typical jhbuild commands (build, buildone, list, info, update, updateone) as DBus methods.
   * Implement signaling. Any application willing to know the state of builds could hook to signals like "end_module", "start_phase", etc.

This would be useful to integrate JHBuild with other integration tools like tinderbox/buildbot. A clean DBus API would be great to invoke jhbuild from these tools.
Comment 1 Jose Dapena Paz 2006-07-24 11:32:12 UTC
Created attachment 69483 [details] [review]
This patch adds a dbus frontend to jhbuild.

To run the jhbuild as a dbus frontend you have to execute "jhbuild dbus". It starts a loop waiting for dbus calls.

I added the following DBus interfaces:
   * dict:string,dict:string,string info (array:string modulelist): returns the information about the modules requested.
   * array:struct:string,string list (array:string modulelist): returns the list of required dependencies required to compile the module list.
   * async update (array:string modulelist, array:string skiplist, string start, string datespec): updates the modules in modulelist and their dependencies, starting in start parameter, ignoring the modules in skiplist. The checkouts will be obtained using the datespec.
   * async updateone (array:string modulelist, string datespec): updates the modules in modulelist. The checkouts will be obtained using the datespec.
   * async build (array:string modulelist, array:string skiplist, string start, string datespec, dict:string,string options): builds the modules in modulelist and their dependencies, starting in start parameter, ignoring the modules in skiplist. The checkouts will be obtained using the datespec. The options parameter is a dictionary of additional options. They can be autogen (forces autogen.sh of the module), clean (calls make clean before compiling the modules) and nonetwork (forces avoiding access to network, and then, avoids accessing version control repositories).
   * async buildone (array:string modulelist, string datespec, dict:string,string options): builds the modules in modulelist. The checkouts will be obtained using the datespec. The options work in the same way as in build command.
   * void set_autogen(boolean enabled): set the global autogen parameter value. If set, it will run always autogen.sh before compiling modules.
   * boolean get_autogen(): obtains the current global autogen parameter value.
   * void set_clean(boolean enabled): set the global makeclean parameter value. If set, it will run always run make clean before compiling modules.
   * boolean get_clean(): obtains the current global autogen parameter value.
   * void set_nonetwork(boolean enabled): set the global nonetwork parameter value. If set, it will run always avoid networks access (and checkouts) for build and buildone commands.
   * boolean get_nonetwork(): obtains the current global nonetwork parameter value.
   * struct:string,string,string get_status(): obtains the current compilation status. The struct has three fields: the current command (build, buildone, updateone, update), the current module, and the status/phase (idle, build, checkout, …).

You can hook to the following signals:
   * start_build_signal (): called when a build starts.
   * end_build_signal (array:string failures):called when the build ends. failures contains the list of modules that did fail.
   * start_module_signal (string module): called when a module build starts. module contains the name of the module.
   * end_module_signal (string module, boolean failed): called when a module build ends. module contains the name of the module. failed tells if the module build has failed.
   * start_phase_signal (string module, string state): called when a phase in the build of a module begins. module contains the name of the module. state contains the name of the phase.
   * end_phase_signal (string module, string state, boolean failed): called when a phase in the build of a module ends.module contains the name of the module. state contains the name of the phase. failed tells if the build phase has failed.
   * message (string message): all the messages from compilation logs are sent through this signal. If you want to retrieve the compilation log, you should hook and get all this messages. This signal is called in each phase with a frequency of 5 seconds.
Comment 2 James Henstridge 2006-07-25 22:11:52 UTC
Would you care to elaborate on what you want to use this interface for?  It is a bit difficult to review such a patch without that information.
Comment 3 Jose Dapena Paz 2006-07-26 10:48:28 UTC
(In reply to comment #2)
> Would you care to elaborate on what you want to use this interface for?  It is
> a bit difficult to review such a patch without that information.

In continuous integration tools like tinderbox or buildbot, we usually require (in order of importance, first is most):
1. A way to request compiling and know the process end status. For example, we build gtk and we want to know if the build has failed. Of course, in an environment like jhbuild we need to specify which module we want to compile.
2. A way to get the compilation log after the build, in order to publish it.

But, if we want to provide real time information of the compilation status, we would require more:
3. A way to get the current log (preferrable to get the log on an incremental method).
4. A way to know the stage it's currently running (best is most accurate).

For example, in a tinderbox environment, we want to compile all the gnome 2.16 daily.
   * It will retrieve the modules in the required order using jhbuild list.
   * Then it begins a loop to compile all the modules using jhbuild buildone <module>. It gets the logs and parses them to retrieve the errors and know the step it's running or the step it has failed.
   * These logs and status are published in a webpage, and through rss, in order to let the developer know the build status of the projects he's involved.

Other use cases would involve getting information about each modules (to be published in the tinderbox webpage).

With dbus I get a better way to communicate with the jhbuild builder, taking advantage of the buildscript class hooks. It also provides a way to reuse the same python vm among different jhbuild calls.

Note: when I talk about tinderbox I mean Mozilla tinderbox.
Comment 4 Frederic Peters 2007-12-16 12:14:23 UTC
Jose, is this patch still necessary for the buildbot work ?  Otherwise I will mark this bug report as obsolete.
Comment 5 Frederic Peters 2008-06-22 19:56:53 UTC
Marking bug as obsolete; please feel free to reopen if needed.