-----BEGIN PGP SIGNED MESSAGE-----
On 05.12.2013 10:38, Tomáš Chvátal wrote:
The verification is actually half done, we wrote
staging plugin for
osc and this is mostly the only part that is done and working -
checking whether staging project contains only links without any
What needs to be added is checking if the changes are all part of
the GR# or actually already merged in factory if it is the fact. As
now the checker just validates that all the changes are back in
So we basically need a new project type along with a new request type
in OBS. Along with maintenance_incident we need staging.
The script now can create staging (might need adjustment to be the
no-publish repo and maybe other tweaks to reduce the load) and
check if it is clean (no changes directly in there) and of course
delete the staging, but without verification for now so it can in
fact wipe almost anything even if you don't want it to.
There are also completely empty functions to push to factory, eg
mark the grouprequest as passed over staging if it is the fact. And
function to submit the stuff back to devel projects from the
changes within the staging (that one is easy to do but we didn't
work there yet as it was lower on the testing list).
IMO we basically need to find out what problems
are common to all
models and start hacking. Once we're there, we can test different
scenario. The models will only be as good as the tools to support
The problems we faced there were more on the tooling side which we
can overcome by writting the api where needed (which I personaly
can't do even if I try best, I wrote like 20 lines top in Ruby).
might be enough in some cases ;)
So the issues we faced:
If you create loads of stagings the wait-on-result was quite
longish TM. MIght be solved by not publishing it or creating them
as "frozen" set that can be refreshed when needed.
Hmm, as I just
implemented mail notifications, I think one missing is
actually project finished to build - as a result you wait for. 20
lines might do ;)
No way how to update the staging for now. Our plan was to use the
groups in a way where you could call update, and it would check the
grouping request that is in the staging and refresh it based on new
submissions in there if needed (could be also hook on group request
that each time the GR is updated the staging is refreshed, would be
probably much better than command on the client side).
Addition is not written, you have to do the linkpac yourself in the
repo now. Might be better to allow it in two ways, adding directly
to group request (with osc group add) or via staging where you can
do (osc staging add SR#) which would do the same; add SR# to the
staging groupID and update the project.
If you look on the repo there is .dot file which has "workflow" as
thought us and it is heavily dependant on the grouping requests at
least how we pictured it. So we need to adjust the groupings to be
able to accept them, get properly their state and status of all
subrequests within the group.
This needs to be handled in the webui properly, I agree.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org