Thanks for posting this. My concern as a consumer of JJB is that reviewers
will lose interest in reviewing JJB patches and move on if JJB is no longer
a necessary component of OpenStack CI (I feel like we are already seeing
this today). A plan is needed to ensure that there are and will continue to
+1
It would be handy for us if there was a new release.
Thanh
On 3 December 2015 at 12:02, James E. Blair wrote:
> Paul Belanger writes:
>
> > On Thu, Dec 03, 2015 at 11:18:50AM +0100, Andreas Jaeger wrote:
> >> If you run "tox -e jjb" locally in project-config, it will fail since it
> >> use
Hi JJB Devs,
We discovered what seems to be a regression with JJB 1.4.0 which after some
git bisecting found it was caused by this patch [1]. My Jenkins verify
builds are failing to pass due to python runtime error:
RuntimeError: maximum recursion depth exceeded
This error follows what seems
>
> [1]
> https://review.openstack.org/gitweb?p=openstack-infra/jenkins-job-builder.git;a=blob;f=jenkins_jobs/cmd.py;h=efafdf05fa35f93a00633489dde160c06930641d;hb=b023d7e23f77e4de33e740dcc37af911e36fb189#l115
>
> On Thu, Jan 7, 2016 at 5:40 PM, Thanh Ha
> wrote:
> > Hi JJB
On 9 January 2016 at 07:10, Darragh Bailey wrote:
>
> Hi Thanh,
>
> On 8 Jan 2016 21:47, "Thanh Ha" wrote:
> >
> > (I truncated some of the repetitive output below)
> >
> > I just tried with the -o argument and seems like it passes. I guess
On 11 January 2016 at 11:03, Thanh Ha wrote:
> On 9 January 2016 at 07:10, Darragh Bailey
> wrote:
>
>> On 8 Jan 2016 21:47, "Thanh Ha" wrote:
>>
>> >
>> > (I truncated some of the repetitive output below)
>> >
>> > I just trie
"-o /path/to/dir" option to the test command to redirect the output to a
directory.
Thanh
[1] https://review.openstack.org/265959
On 11 January 2016 at 12:51, Darragh Bailey wrote:
> Hi Thanh
>
> On 11 January 2016 at 16:03, Thanh Ha
> wrote:
> > Hi Darragh,
> &g
Hi Everyone,
It seems to me that JJB 1.4.0's delete-all function has regressed and no
longer performs the delete function. Instead it simply provides the
following output and exits without performing any deletes.
Sure you want to delete *ALL* jobs from Jenkins server?
(including those not managed
ins directly.
>
> On Sun, Jan 17, 2016 at 5:03 PM, Thanh Ha
> wrote:
> > Hi Everyone,
> >
> > It seems to me that JJB 1.4.0's delete-all function has regressed and no
> > longer performs the delete function. Instead it simply provides the
> > followi
t; Any chance you could try and capture the return value from those lines?
>
>
> On 19 January 2016 at 18:00, Wayne Warren wrote:
> > What command line flags did you pass?
> >
> > I don't generally use this or the 'delete' subcommand, preferring
> > ins
o select a specific job type if desired. We don't need that
parameter for the delete-all command.
Regards,
Thanh
[1] https://review.openstack.org/275993
On 20 January 2016 at 10:16, Thanh Ha wrote:
> Sure thing, I'll try to find some time this week to investigate. Thanks
> fo
Hi Everyone,
I'd like to discuss the usefulness of optional parameters in JJB. We've
been hit by a behaviour that is in my opinion indeterministic and causes
confusion as well as inconvenience as a user. I was reminded by this in
discussions in this patch [1] but then again this weekend while we w
Bumping since I feel this is an important discussion. Darragh, Wayne, any
thoughts on this one?
Thanks,
Thanh
On 8 February 2016 at 10:46, Thanh Ha wrote:
> Hi Everyone,
>
> I'd like to discuss the usefulness of optional parameters in JJB. We've
> been hit by a behaviour
Hi David,
Thanks for commenting!
Sorry below is going to be a bit long but I hope my examples makes the
point clear that we can see very inconsistent behaviour for configuration
sections and it's difficult to tell which one to expect.
On 15 February 2016 at 10:02, David Caro wrote:
>
> What ha
On 16 February 2016 at 10:03, Darragh Bailey
wrote:
> Think it all comes down to the following:
> * Need to understand what exactly is happening within Jenkins with
> regard to XML updating, clearly not just taking the XML given and
> changing to match that, more likely some kind of merge is goin
Hi Everyone,
I'm trying to nest template variables and discovered that JJB behaves in a
way I didn't expect when a template variable is nested. For example:
- project:
name: test
jobs:
- '{name}-verify-{value}-{jdk}'
value:
- a:
jdk:
- open
On 1 March 2016 at 10:08, David Caro wrote:
> On 02/17 16:52, Thanh Ha wrote:
> > On 16 February 2016 at 10:03, Darragh Bailey
> > wrote:
> >
> > > Think it all comes down to the following:
> > > * Need to understand what exactly is happening within Je
ing I understand your intent correctly.
>
> -- Forwarded message --
> From: Darragh Bailey
> Date: 14 March 2016 at 14:51
> Subject: Re: [OpenStack-Infra] JJB nested template variables
> To: Thanh Ha
>
>
>
> Hi Thanh,
>
> On 9 Mar 2016 22:47, "
Hi Everyone,
I've been meaning to bring this up for awhile. It seems some plugins are
getting a bit smarter and using the "parser.registry.get_plugin_info"
command to parse plugin versions to figure out what version of a plugin is
installed in Jenkins.
Unfortunately it's come to our attention tha
a possible solution to the Administrator
permissions issue assuming that providing the plugins_info yaml file causes
JJB to not query the live Jenkins system for the info.
Regards,
Thanh
On 7 June 2016 at 15:34, Thanh Ha wrote:
> Hi Everyone,
>
> I've been meaning to bring this up f
On 8 June 2016 at 08:51, Darragh Bailey wrote:
> On 7 June 2016 at 21:35, Thanh Ha wrote:
>
>> Taking a look at the code, I realized the test command allowed spoofing
>> of the plugins_info. I thought I'd try and see what happens if we allowed
>> spoofing wi
I took a look at the groovy script idea. I think it might work but would be
a bit more involved than the example. It seems
Jenkins.instance.pluginManager.plugins simply prints a list of all plugins
without their details like version etc...
Regards,
Thanh
On 14 June 2016 at 20:11, Zaro wrote:
>
Fridays work for me too.
Regards,
Thanh
On 5 July 2016 at 14:03, Darragh Bailey wrote:
> It's starting to sound like Friday would suit people best, I'm happy
> enough with that day as well, may have to leave slightly before 17hr utc,
> but should be able to be present for most of the time.
>
>
Hi Everyone,
I'd like to keep the momentum of JJB 2.0 work going as we're so close to
the finish line. This Friday we're going to continue our sprint in
#openstack-sprint for those who can make it. Wayne suggested we send a
status to the mailing list for those who can't.
To summarize some of the
On Thu, Nov 10, 2016 at 12:07 PM, Wayne Warren wrote:
> On Wed, Nov 9, 2016 at 6:41 PM, Thanh Ha
> wrote:
>
>> There's 2 patches that need one more core-review to get merged so
>> hopefully someone can take a look at them soon:
>>
>> https://review.openstac
+1 to that.
My org is very much looking forward to the 2.0.0 release as we refuse to
use the master stream. I do think work needs to be done to fix the YAML
parser issue identified in the linked meeting and consider it blocking as
we use this feature heavily in our own instance.
It's been slow bu
#x27;m not familiar with JJB internals), but I can do some testing of
> patches. So feel free to add me to your gerrit CRs if you think you need
> that!
>
>
> Regards,
> Artem
>
> 2017-10-17 18:20 GMT+03:00 Thanh Ha :
>
>> +1 to that.
>>
>> My org is very mu
On 23 May 2018 at 03:17, Sorin Ionuț Sbârnea
wrote:
> Hi
>
> Can someone help updating the *jenkins-job-builder-release* group on
> gerrit to add two persons to it? Apparently there is no way to raise a CR
> to update group membership, or if it is I am unaware about it.
> https://review.openstack
28 matches
Mail list logo
