> The plug in would just be triggering a
> jenkins job using rest or some other mechanism
And obviously make sure it resists abuse/attacks.
On Fri, Jul 17, 2015 at 3:17 AM, Norbert Thiebaud
wrote:
> On Thu, Jul 16, 2015 at 2:26 AM, Stephan Bergmann
> wrote:
> >
> > * Sometimes, a build fails f
On Thu, Jul 16, 2015 at 2:26 AM, Stephan Bergmann wrote:
>
> * Sometimes, a build fails for spurious reasons midway through, and you need
> to start another build. But the only way to re-trigger a build is to rebase
> the change.
This is a way to get an automatic trigger.. but it _is_ possible t
On Mon, Thu Jul 16 00:26:35 PDT 2015, Stephan Bergmann wrote:
> But when you try to (mis-)use it to modify a change
> request [...] the situation is not that ideal.
As you noticed, these are two entirely different use cases:
1. automatic "ready-to-go" gerrit change verification on all platforms
One way to do this is to make gerrit build broken platforms until all pass,
then, when all pass but not the same commit hash, it rebuilds the ones
behind. So in the end they would all have been built on the latest (in case
something broke in the interim).
In this "build failed platforms only" mode
Our gerrit/jenkins setup is fine in detecting change requests that would
break the build. But when you try to (mis-)use it to modify a change
request until it passes on all platforms (because you don't have direct
access to one of the platforms, say), the situation is not that ideal.
As I rece