create new role that allows to trigger rebuilds

[lnussel]

OBS all too often needs somebody who can manually trigger rebuilds. That role should not necessarily have full access to modify packages or review requests. Therefore separate from maintainer and reviewer.
Examples where this would be useful are the distro projects, staging and ports.

[hennevogel]

Can you explain why only triggering builds is needed?

[lnussel]

random build failures spoil the fun. I check in stuff, obs works on it over night or weekend and produces random build failures. If I have to review and trigger those myself Monday morning we lose time. If there was a role for triggering rebuilds more community person could help.

[adrianschroeter]

Having random build failures means you have a not maintainable distribution IMHO. I am not sure if we want to have a role for that. In first place we should find the reason for random failures and work on that.

Has anything changed lately that this is needed suddenly? Any new errors which do appear?

[lnussel]

you are welcome to play staging master for a week or so

[DimStar77]

random build failures include: syswrite: no disk space

[coolo]

those are actually supposed to be handled as bad jobs. build greps for errors like that.

[adrianschroeter]

yep, do you have examples where it did not work?

However, you should add constraints to avoid wasting our build power by too many attempts just by accident finding a proper build host.

(seems my mail answer is lost .... )

[lnussel]

Result of tonight's Leap stagings are failures of gdb, graphviz, libkolab-qt5, java-1_7_0-openjdk-bootstrap. Only in the graphviz looks like a worker related issue, the other are random build failures due to races in make -j or whatever.

In graphviz case:
[29380s] ### WATCHDOG MARKER END ###
[29380s] No buildstatus set, either the base system is broken (kernel/initrd/udev/glibc/bash/perl)
[29380s] or the build host has a kernel or hardware problem...

Job seems to be stuck here, killed. (after 28800 seconds of inactivity)

[adrianschroeter]

can you please store the entire build log the next time when it failed? it is gone now...

[adrianschroeter]

On Montag, 24. Oktober 2016, 08:04:07 CEST wrote Dominique Leuenberger:

random build failures include: syswrite: no disk space

this means you lack _constraints in first place.

But IMHO we have also code which should mark this job as badhost result.
Do you have an example where it did not work?

Adrian Schroeter
email: [email protected]

SUSE Linux GmbH, GF: Felix Imend�rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N�rnberg)

Maxfeldstra�e 5
90409 N�rnberg
Germany

[DimStar77]

There we go: random build fails that are due to OBS and not due to package issues:

https://build.opensuse.org/package/live_build_log/GNOME:Next/gnome-contacts/openSUSE_Factory/i586

https://build.opensuse.org/package/live_build_log/GNOME:Next/gnome-terminal/openSUSE_Factory/x86_64

https://build.opensuse.org/package/live_build_log/GNOME:Next/gnome-maps/openSUSE_Factory/i586

[lnussel]

Any update here?

We have one person applying to participate in release management tasks and we don't want to hand out maintainer privileges right away...

Maybe the privilege could also be used for the /status route then. So someone going over build fails can also take notes without requiring to be maintainer. https://build.opensuse.org/project/status/openSUSE:Leap:42.3

[adrianschroeter]

definitly not a role for this, since it makes the permission checks way more complex.

we may can think about some trigger system for specific commands via tokens, like we do for service runs instead.

[dirkmueller]

@adrianschroeter any update on the implementation status of the tokens support?

[lnussel]

hmm, I wonder if we could do this via attributes. We could introduce an attribute settable staging-managers that indicates the requirement to trigger a rebuild on a specific package. Privileged bots could query that regularly and execute the rebuild. That would also allow to defer or block triggering rebuilding to eg when there is a checkin next time. After all it's sometimes desirable to get isos and ftp tree done first.

[coolo]

that brings me back to an rabbitmq event when an attribute value is created :)

It sounds like an easy enough approach - a little quirky, but very OBSish :)

[ggardet]

Related PR: #6965

[dirkmueller]

the previously implemented behavior has been broken with further changes, so there is a followup PR to add tests and fix it to work again:

#15119