On 08/14/2014 12:35 AM, Russell Bryant wrote:
> On 08/13/2014 06:23 PM, Mark McLoughlin wrote:
>> On Wed, 2014-08-13 at 12:05 -0700, James E. Blair wrote:
>>> cor...@inaugust.com (James E. Blair) writes:
>>>
Sean Dague writes:
> This has all gone far enough that someone actually wrot
On Wed, Aug 13, 2014 at 12:05:27PM -0700, James E. Blair wrote:
> cor...@inaugust.com (James E. Blair) writes:
>
> > Sean Dague writes:
> >
> >> This has all gone far enough that someone actually wrote a Grease Monkey
> >> script to purge all the 3rd Party CI content out of Jenkins UI. People
> >
On Wed, 13 Aug 2014 18:52:05 -0400
Jay Pipes wrote:
> On 08/13/2014 06:35 PM, Russell Bryant wrote:
> > On 08/13/2014 06:23 PM, Mark McLoughlin wrote:
> >> On Wed, 2014-08-13 at 12:05 -0700, James E. Blair wrote:
> >>> cor...@inaugust.com (James E. Blair) writes:
> >>>
> Sean Dague writes:
Chmouel Boudjnah writes:
> On Wed, Aug 13, 2014 at 6:27 PM, James E. Blair wrote:
>
>> If it is not worth looking at a job that is run by the OpenStack CI
>> system, please propose a patch to openstack-infra/config to delete it
>> from the Zuul config. We only want to run what's useful, and we
On 08/13/2014 06:35 PM, Russell Bryant wrote:
On 08/13/2014 06:23 PM, Mark McLoughlin wrote:
On Wed, 2014-08-13 at 12:05 -0700, James E. Blair wrote:
cor...@inaugust.com (James E. Blair) writes:
Sean Dague writes:
This has all gone far enough that someone actually wrote a Grease Monkey
scr
On Wed, Aug 13, 2014 at 6:27 PM, James E. Blair wrote:
> If it is not worth looking at a job that is run by the OpenStack CI
> system, please propose a patch to openstack-infra/config to delete it
> from the Zuul config. We only want to run what's useful, and we have
> other methods (the silent
On 08/13/2014 06:23 PM, Mark McLoughlin wrote:
> On Wed, 2014-08-13 at 12:05 -0700, James E. Blair wrote:
>> cor...@inaugust.com (James E. Blair) writes:
>>
>>> Sean Dague writes:
>>>
This has all gone far enough that someone actually wrote a Grease Monkey
script to purge all the 3rd Par
Chmouel Boudjnah writes:
> On Wed, Aug 13, 2014 at 3:05 PM, James E. Blair wrote:
>
>> You may have noticed that this has merged, along with a further change
>> that shows the latest results in a table format. (You may need to
>> force-reload in your browser to see the change.)
>>
>
>
> Very co
On Wed, 2014-08-13 at 12:05 -0700, James E. Blair wrote:
> cor...@inaugust.com (James E. Blair) writes:
>
> > Sean Dague writes:
> >
> >> This has all gone far enough that someone actually wrote a Grease Monkey
> >> script to purge all the 3rd Party CI content out of Jenkins UI. People
> >> are w
On Wed, Aug 13, 2014 at 3:05 PM, James E. Blair wrote:
> You may have noticed that this has merged, along with a further change
> that shows the latest results in a table format. (You may need to
> force-reload in your browser to see the change.)
>
Very cool!! this is really nice UI, super use
Dan Smith writes:
>> You may have noticed that this has merged, along with a further change
>> that shows the latest results in a table format. (You may need to
>> force-reload in your browser to see the change.)
>
> Friggin. Awesome.
>
>> Thanks again to Radoslav Gerganov for writing the origin
> You may have noticed that this has merged, along with a further change
> that shows the latest results in a table format. (You may need to
> force-reload in your browser to see the change.)
Friggin. Awesome.
> Thanks again to Radoslav Gerganov for writing the original change.
Thanks to all in
cor...@inaugust.com (James E. Blair) writes:
> Sean Dague writes:
>
>> This has all gone far enough that someone actually wrote a Grease Monkey
>> script to purge all the 3rd Party CI content out of Jenkins UI. People
>> are writing mail filters to dump all the notifications. Dan Berange
>> filte
On 07/04/2014 08:11 AM, Duncan Thomas wrote:
> On 2 July 2014 16:11, Anita Kuno wrote:
>> Hmmm, my first response - given that long chew we had on the ml[0] about
>> the use of the word certified as well as the short confirmation we had
>> in the tc meeting[1] that the word certified would not be
On 2 July 2014 16:11, Anita Kuno wrote:
> Hmmm, my first response - given that long chew we had on the ml[0] about
> the use of the word certified as well as the short confirmation we had
> in the tc meeting[1] that the word certified would not be used, but
> rather some version of the word 'teste
On 07/01/2014 10:03 AM, Duncan Thomas wrote:
> On 1 July 2014 14:44, Anita Kuno wrote:
>
>> On 07/01/2014 05:56 AM, Duncan Thomas wrote:
>>> For the record, cinder gave a very clear definition of success in our
>>> 3rd party guidelines: Passes every test in tempest-dsm-full. If that
>>> needs doc
gt; https://review.openstack.org/#/c/93141/1/modules/openstack_project/files/jenkins_job_builder/config/devstack-gate.yaml
>
> -Original Message-
> From: Duncan Thomas [mailto:duncan.tho...@gmail.com]
> Sent: Tuesday, July 01, 2014 7:03 AM
> To: OpenStack Development Mailing List (not for u
ns)
Subject: Re: [openstack-dev] [all] 3rd Party CI vs. Gerrit
On 1 July 2014 14:44, Anita Kuno wrote:
> On 07/01/2014 05:56 AM, Duncan Thomas wrote:
>> For the record, cinder gave a very clear definition of success in our
>> 3rd party guidelines: Passes every test in tempe
On 1 July 2014 14:44, Anita Kuno wrote:
> On 07/01/2014 05:56 AM, Duncan Thomas wrote:
>> For the record, cinder gave a very clear definition of success in our
>> 3rd party guidelines: Passes every test in tempest-dsm-full. If that
>> needs documenting somewhere else, please let me know. It may o
On 07/01/2014 05:56 AM, Duncan Thomas wrote:
> On 30 June 2014 16:49, Anita Kuno wrote:
>
>> Right now that dashboard introduces more confusion than it alleviates
>> since the definition of "success" in regards to third party ci systems
>> has yet to be defined by the community.
>
> For the reco
On 30 June 2014 16:49, Anita Kuno wrote:
> Right now that dashboard introduces more confusion than it alleviates
> since the definition of "success" in regards to third party ci systems
> has yet to be defined by the community.
For the record, cinder gave a very clear definition of success in ou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> There is a similar old bug for that, with a good suggestion for how
> it could possibly be done:
>
> https://bugs.launchpad.net/openstack-ci/+bug/1251758
This isn't what I'm talking about. What we need is, for each new
patchset on a given change, a
On 06/30/2014 11:41 AM, Ilya Shakhat wrote:
> 2014-06-30 19:17 GMT+04:00 Kurt Taylor :
>
>> Dan Smith wrote on 06/27/2014 12:33:48 PM:
>>> If it really does show up right in Gerrit as if it were integrated,
>>> then that would be fine with me. I think the biggest problem we have
>>> right now is
2014-06-30 19:17 GMT+04:00 Kurt Taylor :
> Dan Smith wrote on 06/27/2014 12:33:48 PM:
> > If it really does show up right in Gerrit as if it were integrated,
> > then that would be fine with me. I think the biggest problem we have
> > right now is that a lot of the CI systems are very inconsisten
Sean Dague wrote on 06/30/2014 06:03:50 AM:
> From:
>
> Sean Dague
>
> To:
>
> "OpenStack Development Mailing List (not for usage questions)"
> ,
>
> Date:
>
> 06/30/2014 06:09 AM
>
> Subject:
>
> Re: [openstack-dev] [all] 3rd Part
Dan Smith wrote on 06/27/2014 12:33:48 PM:
>
> > What if 3rd Party CI didn't vote in Gerrit? What if it instead
> > published to some 3rd party test reporting site (a thing that
> > doesn't yet exist). Gerrit has the facility so that we could inject
> > the dashboard content for this in Gerrit in
Joshua Hesketh writes:
> On 6/28/14 10:40 AM, James E. Blair wrote:
>> An alternate approach would be to have third-party CI systems register
>> jobs with OpenStack's Zuul rather than using their own account. This
>> would mean only a single report of all jobs (upstream and 3rd-party)
>> per-pat
On 06/29/2014 09:39 AM, Joshua Hesketh wrote:
> On 6/28/14 10:40 AM, James E. Blair wrote:
>> An alternate approach would be to have third-party CI systems register
>> jobs with OpenStack's Zuul rather than using their own account. This
>> would mean only a single report of all jobs (upstream and
On Sat, Jun 28, 2014 at 08:26:44AM -0500, Matt Riedemann wrote:
>
>
> On 6/27/2014 7:35 AM, Daniel P. Berrange wrote:
> >On Fri, Jun 27, 2014 at 07:40:51AM -0400, Sean Dague wrote:
> >>It's clear that lots of projects want 3rd Party CI information on
> >>patches. But it's also clear that 6 months
On 6/28/14 10:40 AM, James E. Blair wrote:
An alternate approach would be to have third-party CI systems register
jobs with OpenStack's Zuul rather than using their own account. This
would mean only a single report of all jobs (upstream and 3rd-party)
per-patchset. It significantly reduces clut
Matt Riedemann writes:
> I would be good with Jenkins not reporting on a successful run, or if
> rather than a comment from Jenkins the vote in the table had a link to
> the test results, so if you get a -1 from Jenkins you can follow the
> link from the -1 in the table rather than the comment (t
On 6/27/2014 7:35 AM, Daniel P. Berrange wrote:
On Fri, Jun 27, 2014 at 07:40:51AM -0400, Sean Dague wrote:
It's clear that lots of projects want 3rd Party CI information on
patches. But it's also clear that 6 months into this experiment with a
lot of 3rd Party CI systems, the Gerrit UI is rea
Sean Dague writes:
> This has all gone far enough that someone actually wrote a Grease Monkey
> script to purge all the 3rd Party CI content out of Jenkins UI. People
> are writing mail filters to dump all the notifications. Dan Berange
> filters all them out of his gerrit query tools.
I should
Sean Dague writes:
> It seems what we actually want is a dashboard of these results. We want
> them available when we go to Gerrit, but we don't want them in Gerrit
> itself.
I agree with most of what you wrote, particularly that we want them
available in Gerrit and with a sensible presentation.
I do quite like the conflicts with part, I was thinking about that the
other day. That would be hugely useful.
-Sean
On 06/27/2014 02:56 PM, Zaro wrote:
> David did suggest adding REST api endpoints to get data for each channel
> so it doesn't necessarily require you to even use the gerri
David did suggest adding REST api endpoints to get data for each channel so
it doesn't necessarily require you to even use the gerrit web ui. However
the web UI's old screen is pretty much dead so I assume the presentation
would only be available in new change screen. I know Openstackers have had
On 06/27/2014 02:19 PM, Zaro wrote:
>
> Sean, there is a proposal[1] in upstream gerrit to fix this issue.
> David's proposal is to make Gerrit handle multiple notifications
> channels per project which would allow us to treat bot notifications
> differently than human notifications. He has the
Sean, there is a proposal[1] in upstream gerrit to fix this issue. David's
proposal is to make Gerrit handle multiple notifications channels per
project which would allow us to treat bot notifications differently than
human notifications. He has the same problem as we do, most of his builds
are d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> What if 3rd Party CI didn't vote in Gerrit? What if it instead
> published to some 3rd party test reporting site (a thing that
> doesn't yet exist). Gerrit has the facility so that we could inject
> the dashboard content for this in Gerrit in a littl
On Fri, Jun 27, 2014 at 6:35 AM, Daniel P. Berrange
wrote:
> On Fri, Jun 27, 2014 at 07:40:51AM -0400, Sean Dague wrote:
> > It's clear that lots of projects want 3rd Party CI information on
> > patches. But it's also clear that 6 months into this experiment with a
> > lot of 3rd Party CI systems
On Fri, Jun 27, 2014 at 07:40:51AM -0400, Sean Dague wrote:
> It's clear that lots of projects want 3rd Party CI information on
> patches. But it's also clear that 6 months into this experiment with a
> lot of 3rd Party CI systems, the Gerrit UI is really not great for this.
That's an understateme
On 27/06/14 07:40 -0400, Sean Dague wrote:
It's clear that lots of projects want 3rd Party CI information on
patches. But it's also clear that 6 months into this experiment with a
lot of 3rd Party CI systems, the Gerrit UI is really not great for this.
A couple of things have fallen out of this.
It's clear that lots of projects want 3rd Party CI information on
patches. But it's also clear that 6 months into this experiment with a
lot of 3rd Party CI systems, the Gerrit UI is really not great for this.
A couple of things have fallen out of this. 3rd Party CI bots outnumber
Human comments o
43 matches
Mail list logo