Re: Azure and latency issues

2016-05-17 Thread Jo Shields
 Okay, a co-worker may have found a magical fix - Azure times out idle 
network connections after 4 minutes, but the default value 
for hudson.slaves.ChannelPinger.pingInterval is 5 minutes...

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/1d2953df-d054-4544-b557-e5ef98e7e5d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Azure and latency issues

2016-05-11 Thread Jo Shields
Hi all,

I'm observing a problem with our new Jenkins master, running on an Ubuntu
VM on a high-spec Azure instance - latency between master and workers is
*crazy* high. Like 30 plus seconds:
https://jenkins.mono-project.com/computer/. The SSH-based workers can
generally survive that, but the JNLP workers time out and kill running jobs
(we're using JNLP for non-cloud workers as it makes our network management
way simpler). And Jenkins does a pretty dreadful job of keeping track of
whether workers are connected or not, so I end up having to restart the
master to kick-start things. It's basically a nightmare.

It seems we're not the only people running Jenkins on Azure showing obscene
response times, e.g. http://dotnet-ci.cloudapp.net/computer/ - so the
question is whether anyone else on the list has observed this, or (even
better) resolved it.

The master isn't under high IO, network, memory or CPU load, seems well
supplied with entropy; and the failures don't seem to correlate with Java
GC pauses; so I'm not sure where to point the finger.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CACyRP71rAKJ3Q7k0NqbAY5M3mZivbxbhoHUuPDjspTAkv%2Bvvcg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Building a better catch-up system

2015-03-26 Thread Jo Shields
https://github.com/directhex/jenkins-git-catch-up

/micdrop

When I'm done, it'll optionally allow for merges to be squashed (i.e. if 
someone merges a large branch, that merge commit will be regarded as one 
commit, not as potentially dozens)

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/a95ee400-8ca2-4aea-a9ce-66f867a0b839%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Building a better catch-up system

2015-03-25 Thread Jo Shields
I'm trying to resolve the nearly-a-decade-old bug to allow Jenkins to do
one build per commit, without dirty workarounds in dispatcher jobs.
Currently, it'll bundle together multiple commits received at once - for
example, a user does git push to send more than one commit.

I've written a custom BuildChooser for the git plugin, which correctly
determines a list of commits to build, between the last known build and
HEAD (DefaultBuildChooser basically determines the commitid of HEAD and
passes that down in a single-entry array).

GitSCM.java already contains some code to handle cases where more than one
candidate is received, but I don't quite understand what it's intending
to do - it sets the current build revision to the first entry in the array (
https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitSCM.java#L918-924)
then immediately schedules another build of the same job without any
context whatsoever (
https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitSCM.java#L934-935
)

Is there really nowherere in the API to
do project.scheduleBuild(arbitraryBuildObject) or equivalent, to make
actual use of the candidates array i've already generated? The current
behaviour seems terribly racy (behaviour seems to vary depending on how
quickly I step through breakpoints, and the size of the array). At best,
right now I have it sometimes (but not always) building
last-known-revision..HEAD~1 as the current job then scheduling HEAD as the
next job

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CACyRP70wxCVUHNKQxk0UZnKcLnu-1Y0D416a5TxrNQbonBDsgA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Workflow Plugin questions

2014-12-19 Thread Jo Shields


On Tuesday, 16 December 2014 10:15:31 UTC, Jo Shields wrote:

 Hi,

 We're looking to use Jenkins w/ workflow to replace our in-house CI
 system. However, there's a bunch of stuff that doesn't seem to be
 present in the addin (some of it might be missing features, some might
 be plugin compatibility, some might be me not seeing something in the
 documentation)

 1) How can I change the title of a step in the Running Steps page?
 Shell Script three dozen times is not useful. I'd like to be able to
 change this header.


I've been looking at implementing this, though I find myself a bit confused 
by the code (though I am VERY rusty when it comes to Java - they didn't 
change anything in the language syntax since 2001, right?)

The name of the step comes from DescriptorImpl.getDisplayName() - but this 
method is static, so I can't just have a per-instance name property (with 
default as it is now).

However, the stage step is re-nameable. Yet I don't see how this is done, 
in StageStep.java - what am I missing?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/ec96bfb8-d795-4419-a08b-681d16da0a05%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Workflow Plugin questions

2014-12-17 Thread Jo Shields
On Tue, Dec 16, 2014 at 10:50 AM, James Nord te...@teilo.net wrote:

  Its not possible as far as I am aware - and it was something I mentioned
 a few months ago.

 However - in my previous usage of this - it didn't really matter about the
 50 shell scripts - as they where grouped logically into several areas
 (build it, test it, deploy it to clean test system, test test system,
 deploy it to another test system (with live data), test it, deploy it to
 live...)
 So all we cared about at the top level was which part of the thing failed
 (building, testing or deploying...) - and then when something failed - it
 doesn't matter its called shell script as its failed and you are
 interested in the logs!
 This grouping can be acheived with the 'stage' step.


The more hoops my developers need to jump through, especially as compared
to our existing in-house CI system, the more pushback I get from them about
migrating away from the in-house system to Jenkins. Not being able to see
at a glance which step has failed because they don't have meaningful naming
isn't useful or helpful. Especially in a long list of steps. I could give
every step a named stage, but then I just have output which is twice as
verbose as it needs to be. The Groovy DSL already supports multiple
properties in a step, why not allow either a 'merge the logging of this
step into the parent stage's output' property, or a 'override the name for
this step' property? Does that seem insane?


 Cloudbees announced a really great visualization for this (non free) but
 the basis is there in the open source version for you to write your own
 visualization.
 https://www.cloudbees.com/products/jenkins-enterprise/plugins/workflow-stage-view-plugin


This might be exactly what I'm after - but there doesn't seem to be any
screenshot, or online demo, of the plugin.


 2) How can I time out the build on inactivity? Sometimes our test
 suite can get stuck - we use build-timeout to kill unresponsive processes


 look at the timeout step.

 I believe (not used it) that this is implemented with something like

 timeout('180s') {
 sh 'thisMayHang.sh'
 }


This appears to be for purely killing the process after X period of time.

The Build-timeout plugin supports multiple strategies for timeouts, which
are better suited to variable-length stuff (like test suites, whose
performance isn't guaranteed on a shared VM host):
https://github.com/jenkinsci/build-timeout-plugin/tree/master/src/main/java/hudson/plugins/build_timeout/impl


3) How can I add annotation to Running Steps? For example, that
 screen would be much more useful if a test suite step could explicitly
 list the failed tests right from that page, rather than needing to
 click through to the logs (or use another plugin like
 build-failure-analyzer)


 if your test suite can output junit style reports (or cucumber/gherkin
 maybe coming soon) then you just need to call the plugin to parse these and
 they will be displayed in the main page as a trend etc just like with
 normal jobs.


It's just an example, and again, it's about getting the information density
to a point where it's useful. We also use our summary field for
 reporting on various attributes of the current build environment (such as
the versions and license status of installed components), or which decision
was made for a step where multiple behaviours are valid (e.g. whether or
not an older version of something was overwritten when uploading a
version-numbered file). Sure, it could just be in stdout for the logs for
the step. But, again, it's about getting information density to a point
where it's useful.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CACyRP709HRFvTxX3M7tYHzOEd5d5dKta1C1t3G6jX63_8avqYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Workflow Plugin questions

2014-12-16 Thread Jo Shields


Hi,

We're looking to use Jenkins w/ workflow to replace our in-house CI
system. However, there's a bunch of stuff that doesn't seem to be
present in the addin (some of it might be missing features, some might
be plugin compatibility, some might be me not seeing something in the
documentation)

1) How can I change the title of a step in the Running Steps page?
Shell Script three dozen times is not useful. I'd like to be able to
change this header.

2) How can I time out the build on inactivity? Sometimes our test
suite can get stuck - we use build-timeout to kill unresponsive processes

3) How can I add annotation to Running Steps? For example, that
screen would be much more useful if a test suite step could explicitly
list the failed tests right from that page, rather than needing to
click through to the logs (or use another plugin like
build-failure-analyzer)

Thanks.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/5a9a70f9-25b6-400b-b28c-24190977e793%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.