-----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@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org