There is a running gag built into openQA called interactive mode. It goes like this: "if you need the interactive mode, it's broken". The reason: the so called interactive mode is a collection of hacks - in theory making it possible to update needles in a running test.

But in fact it's a UI desaster that almost never works. So the goal of this hackweek project is to get rid of it - and instead build a real control from the webui into the backend allowing tests to be written on the fly including needle creation/updates. Easy as that.

Looking for mad skills in:


This project is part of:

Hack Week 14 Hack Week 16


  • 7 months ago: cdywan liked openQA IDE
  • over 1 year ago: dheidler liked openQA IDE
  • about 2 years ago: ammartinez disliked openQA IDE
  • about 2 years ago: ammartinez liked openQA IDE
  • about 2 years ago: michals liked openQA IDE
  • Show History


    • coolo
      about 2 years ago by coolo | Reply

      Time to get serious - the base is refactored

    • coolo
      about 2 years ago by coolo | Reply

      Current state of afair:

      To enable interactive mode:

      Javascript of the browser POSTS to /worker/<ID>/commands of the webui Webui does a DBUS call to WebSocket Service WebSocket Service will issue a command to the worker through WS Worker POSTS to the commands process of isotovideo That one will call into the main loop, which then sets the variable

      The problem is not the complexity of this in general - the problem is that the missing return channel / error handling.

      If isotovideo is busy with a long running command (i.e. typestring $theworld), it won't react to the commands requests.

      Having a direct WS line between JS and commands process sounds like the easiest to handle. This would remove the need to adapt 3 more places if I want to adapt the workflow.

      So first step: add a step to create this channel - checking permissions in the process.

    Similar Projects

    This project is one of its kind!