Re: openshift/api and openshift/client-go are authoritative

2017-12-05 Thread Ben Parees
On Tue, Dec 5, 2017 at 4:13 PM, Simo Sorce wrote: > On Tue, 2017-11-28 at 13:58 -0500, David Eads wrote: > > As of https://github.com/openshift/origin/pull/17477, h > > ttps://github.com/openshift/api and https://github.com/openshift/ > client-go are > > the authoritative source

Re: Docker builds in an OpenShift Jenkins slave?

2017-12-05 Thread Ben Parees
On Tue, Dec 5, 2017 at 11:54 AM, Alan Christie < achris...@informaticsmatters.com> wrote: > Thanks again, Ben. > > I run into two problems with your _alternative_ suggestion … it looked > really promising because at least you have access to the pod configuration > (in the Jenkins "Configure

Re: [aos-devel] optimizing go guru

2017-12-05 Thread Luke Meyer
If the answer is just "go guru is dog slow, use something else in that case" then that seems like a useful thing to note in the README :) Along with what people actually use in development. Seems like a number of tools rely on guru but everyone complains about how slow it is on large projects. So

Re: [aos-devel] optimizing go guru

2017-12-05 Thread Luke Meyer
On Tue, Dec 5, 2017 at 10:51 AM, Clayton Coleman wrote: > Openshift and Kubernetes are massive go projects - over 3 million lines of > code (last I checked). Initial compile can take a few minutes for these > tools. Things to check: > > 1. Go 1.9 uses less memory when

Re: [aos-devel] optimizing go guru

2017-12-05 Thread Dan Mace
On Tue, Dec 5, 2017 at 10:43 AM, Luke Meyer wrote: > In the context of the vim-go plugin. However behavior seems much the same > if I run the same command at the command line (I pulled it out of ps -ef). > > On Tue, Dec 5, 2017 at 10:40 AM, Sebastian Jug

Re: [aos-devel] optimizing go guru

2017-12-05 Thread Clayton Coleman
Openshift and Kubernetes are massive go projects - over 3 million lines of code (last I checked). Initial compile can take a few minutes for these tools. Things to check: 1. Go 1.9 uses less memory when compiling 2. Be sure you are reusing your go compiled artifacts dir between multiple tools

Re: Docker builds in an OpenShift Jenkins slave?

2017-12-05 Thread Ben Parees
On Tue, Dec 5, 2017 at 10:36 AM, Alan Christie < achris...@informaticsmatters.com> wrote: > Thanks Ben. It does seem sensible to use build strategies but prior to a > wholesale migration to OpenShift, and for existing workflows that may > contain docker and docker-compose commands is there any

Re: [aos-devel] optimizing go guru

2017-12-05 Thread Luke Meyer
In the context of the vim-go plugin. However behavior seems much the same if I run the same command at the command line (I pulled it out of ps -ef). On Tue, Dec 5, 2017 at 10:40 AM, Sebastian Jug wrote: > Are you using guru in some sort of editor/IDE or just standalone? > > On

Fwd: [aos-devel] optimizing go guru

2017-12-05 Thread Luke Meyer
-- Forwarded message -- From: Luke Meyer Date: Tue, Dec 5, 2017 at 10:39 AM Subject: Re: [aos-devel] optimizing go guru To: Sebastian Jug Cc: dev On Tue, Dec 5, 2017 at

Re: Docker builds in an OpenShift Jenkins slave?

2017-12-05 Thread Alan Christie
Thanks Ben. It does seem sensible to use build strategies but prior to a wholesale migration to OpenShift, and for existing workflows that may contain docker and docker-compose commands is there any reasonable option other than a an external (cloud/proprietary/dedicated) docker-enabled slave? I

Re: Docker builds in an OpenShift Jenkins slave?

2017-12-05 Thread Ben Parees
On Dec 5, 2017 07:57, "Alan Christie" wrote: I’m using Jenkins from the CI/CD catalogue and am able to spin up slaves and use an `ImageStream` to identify my own slave image. That’s useful, but what I want to be able to do is build and run Docker images,

Docker builds in an OpenShift Jenkins slave?

2017-12-05 Thread Alan Christie
I’m using Jenkins from the CI/CD catalogue and am able to spin up slaves and use an `ImageStream` to identify my own slave image. That’s useful, but what I want to be able to do is build and run Docker images, primarily for unit/functional test purposes. The _sticking point_, it seems, is the