Mailinglist Archive: opensuse-buildservice (138 mails)

< Previous Next >
Re: [opensuse-buildservice] Qactus, a Qt-based OBS notifier app
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El 03/03/15 a las 08:07, Adrian Schröter escribió:
On Dienstag, 3. März 2015, 00:14:14 wrote Javier Llorente:
El 02/03/15 a las 09:04, Adrian Schröter escribió:
On Freitag, 27. Februar 2015, 23:52:22 wrote Javier Llorente:
Hello everyone!

I have just released the first version of Qactus, a Qt-based
OBS notifier application. Besides the build status viewer,
it features an autocompleter for adding builds to the list
easily and a submit request viewer as well.

More details are available at
http://www.javierllorente.com/2015/02/27/qactus-is-out-in-the-wild/




Very cool :)

Do you need better support in our API somewhere? Maybe to
listen more comfortable any changes?


Right now what comes up to my mind is the following:

- having the possibility of downloading all the SRs and
afterwads, when the user clicks on Qactus' refresh button, just
downloading the new ones and not the whole collection again.

hm, so you want some api call extension to say for example show
only requests > number X?

Should be easy to do ...

That or retrieving only new requests since a certain date (when user
clicks on refresh, for example)

I have also thought of making accepting/declining SRs from the
Requests tab possible.

You may want to check

osc -d results -w

You can see there how osc is monitoring changes by refering to
the old known state so the http call hangs until something
happened.

This is quite interesting. Using it would be a radical change in
terms of Qactus' architecture. One question: once the http call
is terminated, would I need to retrieve the status making another
http call? (ie: a standard GET
https://api.o.o/build/prj/repo/arch/pkg/_status)

No, the result comes with this root element for example:

<resultlist state="ce111a8f5c883f9509c035ac6b1c24ff">


just use the content of the state attribute as parameter to tell
the api what was your last state.

So no need for comparing build status in this case;
1) Wait until something happens (which means finished building). This
terminates the http call.
2) If something has happened, you get the "resultlist" with the new
build status.
3) After this you can keep monitoring the build status by making the
same http call with the content of the state attribute you got in
"resultlist" as "oldstate", and the process starts over.

Qactus could end up with quite a few http connections open.

- From this I have got the idea of monitoring a build for any
arch/repository.
The current version of Qactus just requests "_status" That's it, you
can only add a build for only one arch/repository at a time. It stores
the last status tag and compares it against the most recent one to see
if there have been any changes.

What's the meaning of an asterisk next to a status? That it has
changed recently? I haven't found its meaning on the man page.

It can have two meanings in osc. Either it is the "dirty" flag,
this means the server knows that the scheduler has to check the
repository state again. For example when a source change happened,
but the scheduler did not check the repository state yet. So the
state may still be in succeeded/failed, but it is known that this
is going to change.

The other situation where osc prints the asterik is when the build
has finished, but the repository is not yet published.

When using --verbose switch you see a more detailed output here.
This is the code in osc for this:

if res['dirty']: waiting = True if verbose: res['status'] =
'outdated (was: %s)' % res['status'] else: res['status'] += '*'
elif res['code'] in ('succeeded') and res['repostate'] !=
"published": waiting = True if verbose: res['status'] +=
'(unpublished)' else: res['status'] += '*'

OK. Thanks for explaining it.


Yet another idea, we could add some links in
build.opensuse.org which can be dragged and dropped to qactus.
qactus could use the URL to learn which which
project/package/repo/arch or request should be monitored.
Actually, you could do this already just by seperating the path
of a link to some log file monitor for example ...

That's a cool idea. Drag and drop URLs from your browser directly
into Qactus. As you said, I think no special links would be need.
Qactus could differentiate URLs and get the package to be
monitored from the URL as well.

Right, not for Drag&Drop. But we could also add links to click on.
It would deliver some file with some specific mimetype so the
desktop handler could deliver it to qactus.

But that needs some more thinking about how to integrate it into
current webui.

Yet another good idea. That reminds me of YaST's one click install.

I have created a wiki page with the TODO/ideas and added yours.
https://github.com/javierllorente/qactus/wiki

good morning adrian


Greetings,
- --
Javier Llorente
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlT2SegACgkQdV3zWWOPFxQC0ACfeJ7dUZOnwnDezjIEVXTMhhSX
dY4An2eWJwYfMY/FP/kVOHuyh4FGz9Lo
=6jiM
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-buildservice+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups