Re: Compound build/install problem

[Mark Waite]

I wonder if you could use a series of docker images to provide a location
which can be polluted by installed copies of build articles.  It seems like
a docker image (container based virtualization, available in Debian Jessie)
would let you contaminate the specific virtual machine you need, without
requiring that you contaminate the original slave or the original master.

On Sat, Nov 1, 2014 at 8:24 PM, John Mellor  wrote:

> I've just inherited a complex product suite build environment, and am in
> the process of moving it from a custom build hack into a Jenkins build
> environment.  Company politics aside, it seems like a more scalable way to
> do things.  The product suite runs on and is also built on multiple
> releases of a Debian platform.  I can easily build any one of the 187
> components as a simple C++ automake project, but only if I install much of
> the previously-built product from earlier steps in the build process.  If I
> want to build the whole product suite for a release, I'm unsure how to
> approach this correctly.  Any and all help is hugely appreciated!
>
> The problem is that about half of the individual project builds in the
> product suite have one or more compile-time dependencies on other builds
> earlier in the tree.  Each of the 187 builds produces a .deb installation
> deliverable, and at this point, the only means of getting the dependencies
> available  for higher-level builds is to [gag!] "pollute" the the build
> machine and install them (manually at this point, using sudo dpkg -i).
> This can obviously be automated in a postbuild step, and should work ok for
> building a branch that always move forward such as the next release branch,
> but has several obvious and serious implications for building other
> branches or for fixes for older product branches.  This problem also exists
> with the previous build system, for the same reasons, but was apparently
> never attempted to be resolved by my predecessor.
>
> At this point, I'm toying with the idea of building up a separate Jenkins
> implementation for every branch - its messy but will resolve the
> hermaphroditic install problem for a while.  However, its probably not
> going to work for an active dev branch, where it would be normal to
> withdraw api changes instead of always moving forward.
>
> I also thought about adding all the .h and .so files as deliverables, and
> adding the required path to the LD_LIBRARY_PATH and INCLUDE_PATH, but aside
> from these getting extremely long with 187 of them, some of them (device
> drivers, etc.) extend and replace existing Debian base functionality, so
> its another point where the installed product can be at variance with these
> simplistic path inclusions.
>
> Has anybody got an idea for how to get this to a more scalable and robust
> build environment?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Thanks!
Mark Waite

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Compound build/install problem

[John Mellor]

I've just inherited a complex product suite build environment, and am in 
the process of moving it from a custom build hack into a Jenkins build 
environment.  Company politics aside, it seems like a more scalable way to 
do things.  The product suite runs on and is also built on multiple 
releases of a Debian platform.  I can easily build any one of the 187 
components as a simple C++ automake project, but only if I install much of 
the previously-built product from earlier steps in the build process.  If I 
want to build the whole product suite for a release, I'm unsure how to 
approach this correctly.  Any and all help is hugely appreciated!

The problem is that about half of the individual project builds in the 
product suite have one or more compile-time dependencies on other builds 
earlier in the tree.  Each of the 187 builds produces a .deb installation 
deliverable, and at this point, the only means of getting the dependencies 
available  for higher-level builds is to [gag!] "pollute" the the build 
machine and install them (manually at this point, using sudo dpkg -i).  
This can obviously be automated in a postbuild step, and should work ok for 
building a branch that always move forward such as the next release branch, 
but has several obvious and serious implications for building other 
branches or for fixes for older product branches.  This problem also exists 
with the previous build system, for the same reasons, but was apparently 
never attempted to be resolved by my predecessor.

At this point, I'm toying with the idea of building up a separate Jenkins 
implementation for every branch - its messy but will resolve the 
hermaphroditic install problem for a while.  However, its probably not 
going to work for an active dev branch, where it would be normal to 
withdraw api changes instead of always moving forward.

I also thought about adding all the .h and .so files as deliverables, and 
adding the required path to the LD_LIBRARY_PATH and INCLUDE_PATH, but aside 
from these getting extremely long with 187 of them, some of them (device 
drivers, etc.) extend and replace existing Debian base functionality, so 
its another point where the installed product can be at variance with these 
simplistic path inclusions.

Has anybody got an idea for how to get this to a more scalable and robust 
build environment?

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins ircbot leaking OutputThreads

[Christoph Kutzinski]

Would be great if you could test the build, I linked to the issue, 
before I cut a new release.


Am 01.11.2014 um 12:24 schrieb Luciano Furtado:

Hi Cristoph,

I see that a fix was commited , thank you so much.

Do you have any plans for a new release of the irc plugin ?

Best Regards.

On Tuesday, October 28, 2014 10:50:39 PM UTC, Luciano Rodrigues Furtado
wrote:

Hey Cristoph,


I have opened the ticket as requested JENKINS-25349 - Leaking ircbot
OutputThreads .


Please let me know if I can help in any way.


Cheers.

On Oct 28, 2014 9:17 PM, "Christoph Kutzinski" > wrote:

Thanks for the info.
Can you open a new JIRA issue against the ircbot and attach the
information below?

thanks
Kutzi

Am 28.10.2014 um 22:02 schrieb Luciano Furtado:

Hi Everybody,


We have a Jenkins instance that connects to a irc server over
ipsec, the Jenkins server after running for over a week, ends
up with about 300 OutputThreads for the irc-plugin .

we are running on Jenkins Jenkins ver. 1.565.3
 with irc plugin 2.25


 /
CentOS 6.5 / OpenJdk 1.6

The connection to the irc server is bit flaky , so it seems to
get disconnected from time to time, our theory is that the
OutputThreads are not getting interrupted after the connection
is lost and re-established.

So everytime we reconnect another Outputthread is leaked.


When we take jstack dump  on the jenkins process this is what
we see below (I truncated the output to reduce the size of the
email), please let me know if any further info is need to
throubleshoot this issue:


Thanks in advance,
Luciano


--
"bot283-output" daemon prio=10 tid=0x7fd518159800
nid=0x7b3 waiting on condition [0x7fd3d62e1000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0x0005912d31b0> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at
java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at

java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
at

java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:386)
at org.pircbotx.OutputThread.run(OutputThread.java:101)

--
"bot282-output" daemon prio=10 tid=0x7fd518158800
nid=0x7ff0 waiting on condition [0x7fd3ca6a5000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0x000590b18d98> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at
java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at

java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
at

java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:386)
at org.pircbotx.OutputThread.run(OutputThread.java:101)

--
"bot281-output" daemon prio=10 tid=0x7fd518157800
nid=0x75c9 waiting on condition [0x7fd3cebea000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0x000590219238> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at
java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at

java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
at

java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:386)
at org.pircbotx.OutputThread.run(OutputThread.java:101)

--
"bot280-output" daemon prio=10 tid=0x7fd518156800
nid=0x6f40 waiting on condition [0x7fd3c9f9e000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0x000587ad2da0> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at
java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at

java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
at

java.util.concurrent.

Re: Jenkins ircbot leaking OutputThreads

[Luciano Furtado]

Hi Cristoph,

I see that a fix was commited , thank you so much.

Do you have any plans for a new release of the irc plugin ?

Best Regards.

On Tuesday, October 28, 2014 10:50:39 PM UTC, Luciano Rodrigues Furtado 
wrote:
>
> Hey Cristoph,
>
>
> I have opened the ticket as requested JENKINS-25349 - Leaking ircbot 
> OutputThreads .
>
>
> Please let me know if I can help in any way.
>
>
> Cheers.
> On Oct 28, 2014 9:17 PM, "Christoph Kutzinski" > 
> wrote:
>
>>  Thanks for the info.
>> Can you open a new JIRA issue against the ircbot and attach the 
>> information below?
>>
>> thanks
>> Kutzi
>>
>> Am 28.10.2014 um 22:02 schrieb Luciano Furtado:
>>  
>>  Hi Everybody,
>>
>>  
>>  We have a Jenkins instance that connects to a irc server over ipsec, the 
>> Jenkins server after running for over a week, ends up with about 300 
>> OutputThreads for the irc-plugin . 
>>
>>  we are running on Jenkins Jenkins ver. 1.565.3  
>> with 
>> irc plugin 2.25 
>> 
>>  / 
>> CentOS 6.5 / OpenJdk 1.6
>>
>>  The connection to the irc server is bit flaky , so it seems to get 
>> disconnected from time to time, our theory is that the OutputThreads are 
>> not getting interrupted after the connection is lost and re-established. 
>>
>>  So everytime we reconnect another Outputthread is leaked.
>>
>>  
>>  When we take jstack dump  on the jenkins process this is what we see 
>> below (I truncated the output to reduce the size of the email), please let 
>> me know if any further info is need to throubleshoot this issue:
>>
>>  
>>  Thanks in advance,
>> Luciano
>>
>>  
>>  --
>> "bot283-output" daemon prio=10 tid=0x7fd518159800 nid=0x7b3 waiting 
>> on condition [0x7fd3d62e1000]
>>java.lang.Thread.State: WAITING (parking)
>> at sun.misc.Unsafe.park(Native Method)
>> - parking to wait for  <0x0005912d31b0> (a 
>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>> at 
>> java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
>> at 
>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
>> at 
>> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:386)
>> at org.pircbotx.OutputThread.run(OutputThread.java:101)
>>
>>  --
>> "bot282-output" daemon prio=10 tid=0x7fd518158800 nid=0x7ff0 waiting 
>> on condition [0x7fd3ca6a5000]
>>java.lang.Thread.State: WAITING (parking)
>> at sun.misc.Unsafe.park(Native Method)
>> - parking to wait for  <0x000590b18d98> (a 
>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>> at 
>> java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
>> at 
>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
>> at 
>> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:386)
>> at org.pircbotx.OutputThread.run(OutputThread.java:101)
>>
>>  --
>> "bot281-output" daemon prio=10 tid=0x7fd518157800 nid=0x75c9 waiting 
>> on condition [0x7fd3cebea000]
>>java.lang.Thread.State: WAITING (parking)
>> at sun.misc.Unsafe.park(Native Method)
>> - parking to wait for  <0x000590219238> (a 
>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>> at 
>> java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
>> at 
>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
>> at 
>> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:386)
>> at org.pircbotx.OutputThread.run(OutputThread.java:101)
>>
>>  --
>> "bot280-output" daemon prio=10 tid=0x7fd518156800 nid=0x6f40 waiting 
>> on condition [0x7fd3c9f9e000]
>>java.lang.Thread.State: WAITING (parking)
>> at sun.misc.Unsafe.park(Native Method)
>> - parking to wait for  <0x000587ad2da0> (a 
>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>> at 
>> java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
>> at 
>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
>> at 
>> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:386)
>> at org.pircbotx.OutputThread.run(OutputThread.java:101)
>>
>>  
>>   -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-use...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>  -- 
>> You received this 

Re: [Email-ext] Resolving email address from Cause.UserIdCause

[Nick Dierauf]

Thanks Stuart!
Nick.

On Wednesday, October 29, 2014 12:43:56 PM UTC-7, Stuart Rowe wrote:
>
> Here you go :)
>
>
> import javax.mail.Message
> import hudson.model.*
> import com.cloudbees.plugins.flow.*
> import hudson.tasks.MailAddressResolver
>
> def getUpstreamBuild(AbstractBuild curBuild)
> {
> upStreamBuild = null
> if(curBuild != null)
> {
> // find a cause that will lead to an upstream build
> for( cause in curBuild.causes )
> {
> if(cause instanceof Cause.UpstreamCause)
> {
> upStreamBuild = 
> Hudson.instance.getItem(cause.upstreamProject).getBuildByNumber(cause.upstreamBuild)
> break
> }
> else if(cause instanceof FlowCause)
> {
> upStreamBuild = cause.getFlowRun()
> break
> }
> }
> }
> return upStreamBuild
> }
>
> def getUserIdCause(AbstractBuild curBuild)
> {
> def userIdCause = null
> if (curBuild != null)
> {
> for( cause in curBuild.causes )
> {
> if(cause instanceof Cause.UserIdCause)
> {
> userIdCause = cause
> break
> }
> }
> }
>
> return userIdCause
> }
>
> def getEmailFromUserId(userId)
> {
> email = null
> user = User.get(userId, false, [:])
> if(user)
> {
> email = MailAddressResolver.resolve(user)
> }
> return email
> }
>
> def getRootRequesterUserEmail()
> {
> try
> {
> // try to find a user ID cause for the current build
> def userIdCause = getUserIdCause(build)
> if(userIdCause != null)
> {
> return getEmailFromUserId(userIdCause.getUserId())
> }
>
> def rootBuild = null
> def curUpstreamBuild = getUpstreamBuild(build)
>
> // find the top level build
> while(curUpstreamBuild)
> {
> rootBuild = curUpstreamBuild
> curUpstreamBuild = getUpstreamBuild(curUpstreamBuild)
> }
>
> // try to find a user ID cause from the top level build
> userIdCause = getUserIdCause(rootBuild)
> if(userIdCause != null)
> {
> return getEmailFromUserId(userIdCause.getUserId())
> }
> }
> catch (e)
> {
> println e
> }
> return  null
> }
>
> // update the recipients with the requester from the top level build
> def userEmail = getRootRequesterUserEmail()
> return userEmail
>
>
> On Tue, Oct 28, 2014 at 6:17 PM, Nick Dierauf  > wrote:
>
>> Stuart, can you post the groovy script that you use to determine the 
>> email address (ie, "myscript.groovy")?
>> Thanks!
>> Nick.
>>
>>
>> On Tuesday, March 11, 2014 11:24:37 AM UTC-7, Stuart Rowe wrote:
>>>
>>> Hi, does anyone know of a way to look up a user's email address from 
>>> their user ID? I can't make the assumption that the email is "
>>> use...@company.com" because I know this isn't always the case.
>>>
>>> We're using the Active Directory plugin for security which is where the 
>>> email addresses for users are coming from. I need to manually add the 
>>> requester to the recipient list because this doesn't seem to be propagated 
>>> by BuildFlow FlowCauses. The relevant parts of build pipeline in this case 
>>> is:
>>>
>>> BuildFlow project A (scheduled by the logged in user) --> Build Flow 
>>> project B --> Free Style Project with an Editable Email Notification post 
>>> build step.
>>>
>>> Thanks in advance, 
>>>
>>> Stuart
>>>
>>  -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Jenkins Users" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/jenkinsci-users/nQtro7RisO4/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to 
>> jenkinsci-use...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.