we found the latest jenkins and docker plugin work better together. Older
versions would not always fire up a slave when they where supposed to - or
fired up the wrong slave type!
if you can upgrade to the next soon to be stable LTS and give it a go you
may find it works better.
On Tuesday,
Hi,
have you checked the time sync between the master and slave?
you will get this when Jenkins found test results but they are older then
when the build started (that is they did not come from this build but are
remenants of a previous build)
Regards
/James
On Monday, 13 October 2014
There's a cent jiraComponent issue where jenkins gets confused if you have
multiple test result types (both a Junit report and a cucumber report for
example).
I would argue that cucumber is a different tool to Junit and should be testing
stuff built elsewhere so you should not have this mix in
If the other domain is trusted by the main domain then this should just work.
If it is not trusted the you are very likely out of luck.
--
You received this message because you are subscribed to the Google Groups
Jenkins Users group.
To unsubscribe from this group and stop receiving emails
Best practice is to normally have each branch in a different job.
Otherwise trends and linear history become a bit meaningless.
It also solves your issue as you just use lastStable/api/…
/James
On Wednesday, 9 July 2014 08:54:31 UTC+1, sebastian.nickel wrote:
Hi Darrel,
thank you for
On Thursday, 22 May 2014 16:12:52 UTC+1, Stephen Connolly wrote:
OK, so there is now rumoured to be a faster and better way to look up the
groups that a user belongs to in the LDAP 1.10 plugin.
I say rumoured because due to the complexities of Active Directory server
configurations, one
If you mean the graph you need at least to runs before it will display.
For the individual build you shoul have a Testresult link that will let you
drill down into the results.
If you don't have that can you share the end of your build log.
--
You received this message because you are
Have you checked that your Jenkins user has stream events on the grit instance
that isn't triggering.
--
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
I haven't tried that version but I already know that the ad specific
LDAP_MATCHING_RULE_IN_CHAIN oid breaks very large installations.
One LDAP query will take over 1.5 minutes and will be killed by the ad server.
Last I looked using ad browser which was a few weeks my memberOf did not
include
It shows up for me as part of the standard maven plugin, under a post build
action
--
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
Is there a way to use the ldap plugin with ssl (ldaps) without having to
setup full trust for the cert?
I know what the issues with turning things off like this are - but at least
it is marginally better than just sending username/password in cleartext.
or to put it another way how to quickly
Hi,
Buildflow 0.11 is in the process of releasing and should hit the update
center in a few hours.
This version contains a significant intentional change that may affect you
if you using functionality that was unintentionally exposed.
The Flow is now a flyweight task and as such *has no
center metadata?
E.g.:
https://wiki.jenkins-ci.org/display/JENKINS/Marking+a+new+plugin+version+as+incompatible+with+older+versions
On 08.04.2014, at 21:52, teilo teilo+...@teilo.net javascript: wrote:
Hi,
Buildflow 0.11 is in the process of releasing and should hit the update
fixed - if not raise an issue in JIRA against core and buildflow.
/James
On Friday, 4 April 2014 21:53:08 UTC+1, teilo wrote:
Reproduced the issue locally - but I think the root cause is Jenkins not
the plugin.
On Friday, 4 April 2014 19:04:34 UTC+1, Marc MacIntyre wrote:
The latest
Looks unrelated to me.
On Monday, 7 April 2014 17:36:11 UTC+1, Schalk Cronjé wrote:
It might be related to JENKINS-19656 (
https://issues.jenkins-ci.org/browse/JENKINS-19656).
On Friday, 4 April 2014 21:53:08 UTC+1, teilo wrote:
Reproduced the issue locally - but I think the root cause
3900
characters. Then add the encoding overhead. The GET request is then some
6522 bytes.
When you talk about a fix ... how would we get the fix? Will it go into
the next plugin version?
Sascha
Am Mittwoch, 2. April 2014 22:36:57 UTC+2 schrieb teilo:
Sounds like the flow is validating
Reproduced the issue locally - but I think the root cause is Jenkins not
the plugin.
On Friday, 4 April 2014 19:04:34 UTC+1, Marc MacIntyre wrote:
The latest snapshot doesn't address this; it does abort running subjobs,
and dequeues those that have not started, but if a sub-job is manually
Sounds like the flow is validating the dsl via a http get request.
If the flow is large the http request will be too large for some severs to
handle. This intern causes some headers to be lost on the server, to which
jenkins will the think you are not authenticated and will clear your cookie...
An alternative may be to look at the buildflow plugin (latest source code
not latest release) and one of its extensions.
If you move your pipeline to be managed by the flow - the flow can control
which jobs are allowed to run concurrently (for the same flow) - and the
actual jobs can run as
Depending on what state you want to store you should look at writing
either an extension to the build flow, or a new plugin or a combination of
both.
The states I'd want to store are the polling status of the underlying
subversion repository related to the job,
No workspace so -
Hi Les,
Firstly a workspace will never give you true stateless in Jenkins à workspace
availability is best effort (slave may be unavailable, workspace may be deleted
to reclaim slave disk space...)
Depending on what state you want to store you should look at writing either an
extension to the
2.0 was horribly broken for me with gerrit. 2.0.1 works fine.
--
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
Which cucumber implementation (eg cucumber-jvm) and version are you running the
tests with?
Can you put the offending Jason online somewhere?
It sounds like you have a step that is missing a resuilt , they should all have
even if the step not run.
--
You received this message because you are
If you don't need jdk auto install then try using maven toolchains.
Then run the job with whatever jdk works for maven and Jenkins
--
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,
Take a look in the server logs for any exceptions. I saw something similar when
the jelly rendering of a plugin failed, the exception pointed me at the plugin
which was ultimately caused by an upgrade failing leaving a mix of New and old
plugin classes lying around.
--
You received this
On Tuesday, 21 January 2014 17:02:55 UTC, MoBarger wrote:
Hi - just curious if anyone here has implemented JE.
Yes - many have (including me)
Can same
functionality be achieved with free plugins instead of going with the
paid versions that Cloudbees offers?
No. Some of it can -
I know of a comercial (not free) plugin that does this -
http://www.cloudbees.com/jenkins-enterprise-by-cloudbees-features-label-throttled-build-execution-plugin.cb
As a plugin exists, the answer to your second question about extension
points is answered with a yes - but I'm not sure what they
On Sunday, 12 January 2014 22:20:17 UTC, Abhijith Chandrashekar wrote:
Of course, you'd need a secure way to make sure it's actually his
signature, but that should be easier than changing the entire distribution
chain.
That's exactly the problem. Any ideas on how I can do that?
Thanks,
an interesting target for attacks
Jenkins security is a joke. You can find security issues without trying,
even in core. And the process to resolve them seems to be really broken.
Have you helped to improve this situation by actually reporting them via
the proper channels?
Sounds like you want a shallow clone rather than a full one. you have thus
option on the git plugin for about a year.
That way you won't have all of the history for the clone and hence less disk
space and network traffic is required.
--
You received this message because you are subscribed to
For our commit build we use a change hook on Gerrit that notifies Jenkins, Then
just use normal git setup with polling @yearly.
--
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,
Issues won't get fixed as quickly as they need to be in a release for two weeks
first. That said you are less likely to discover new issues - with the
exception of a new major lts version, however that has an amount of testing
which latest never has.
If you are really concerned with bugs
I believe thus is broken for jobs that use maven3 rather than maven 2. There
is probably a jira issue already for it, off not you should probably raise one.
--
You received this message because you are subscribed to the Google Groups
Jenkins Users group.
To unsubscribe from this group and
Take a look at src/test/groovy/com/cloudbees/plugins/flow/AbortTest.groovy
- this should say that it is possible to do what you want :-)
On Tuesday, 29 October 2013 02:43:19 UTC-4, asmundo wrote:
On Tue, Oct 29, 2013 at 4:16 AM, James Nord (jnord)
jn...@cisco.comjavascript:
wrote:
The
Hi Chris,
The best practice approach is to have a single job per branch.
This not only solves your problem but your trend reports will then have
some form of linear code progression contained within them rather than
jumping all over the shop.
So you are probably trying to fix something that
There is a commercial plugin from cloudbees that will allow you to do this with
VMware.
A single job can have multiple VMs assigned on which you can run commands like
starting your server and then starting your client.
There are possibly other ways but I have not used them.
--
You received
The LDAP plugin is (at least it was before we unceremoniously ditched it)
MUCH MUCH quicker to authenticate users than the AD one when you have a
lovely large tree of domains…
Now I will prefix this with I am not an AD expert but…
you be amenable to firing up a test jenkins and giving some
comparative timings?
At least in Unix mode they should be pretty much identical in performance,
though theAD plugin should be much easier to configure
On 15 October 2013 14:47, teilo teilo+...@teilo.net javascript: wrote
This sounds like you have slaves as well as polling the SCM.
Which is pretty much a bit of a side effect, as the polling will kick off
potentially before the slaves are available - so the last known revision is
not available (its in the workspace) and so a new build is kicked off to
get the
On Wednesday, 25 September 2013 14:49:05 UTC+1, flex...@googlemail.com
wrote:
Hi teilo,
I created the file custom.sh in /etc/profile.d/ folder:
export LANG=en_US.UTF-8
export LC_ALL=en_US.UTF-8
which should (as far I know) set the settings system wide.
no it doesn't - see my earlier
To be honest I wouldn't pass buildnumber, I would use a run parameter so
that manual triggering should you ever need it (e.g. a failed deploy) would
be easier.
Format the build as
def job1runparam = build1.project.fullName + # build1.number
and then add that to the paramerers
def
The BuildFlow doesn't use a workspace anymore[1] - so your workaround most
likely won't work as you expect.
I'm not convinced that this is a good thing as like you I would like to
show test results in the main flow job - not have another job that is just
aggregate report.
On Monday, 12
Hi Christian,
You should create an issue in the Jenkins bug tracker under the Security
Issues project.
This project has restricted access so only the select few will be able to
see your report.
See https://wiki.jenkins-ci.org/display/JENKINS/Security+Advisories for
more info.
/James
On
/2013, with
no response. So I’m not sure what triggers someone to actually look at your
report …
*From:* jenkins...@googlegroups.com javascript: [mailto:
jenkins...@googlegroups.com javascript:] *On Behalf Of *teilo
*Sent:* 29 August 2013 11:48
*To:* jenkins...@googlegroups.com
Hi all,
After a lot of head scratching[1] I found that you can no longer (by
default) use text() in an xpath in api/xml/xpath=blah.
The associated commit references SECURITY-47 - which I can't see but from
the other commit would seem to be related only to jsonp[2]?
What I'm finding hard to
Hi Avyhal,
It's a problem with your tools and workflow.
I suggest you look at some tools that enforce some code review as part of your
SCM use, so that the build midst have passed test before it can be in the
mainline.
E.g Gerrit, cloudbees commit validator etc.
Regards
James
--
You
Another potential reason is the Java security manager that your today is using
is preventing reading and it writing files that are outside the tomcat webapp
dir.
--
You received this message because you are subscribed to the Google Groups
Jenkins Users group.
To unsubscribe from this group
Generally if the fix has been in the mainline for a few weeks without any
regressions and is easy to back port, if it has been tagged then it will be
back ported.
--
You received this message because you are subscribed to the Google Groups
Jenkins Users group.
To unsubscribe from this group
You need too add target/ to svn:ignore
--
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://issues.jenkins-ci.org/browse/JENKINS-755
--
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,
:
I tried someAttribute and it did not work either.
The Groovy code is executed prior to the user entering the template
attributes. This makes using Groovy code not very useful since it can’t be
dynamic.
Bob
*From:* teilo [mailto:teilo+...@teilo.net javascript:]
*Sent
I use option 4 - Jenkins enterprise
This won't be a drop in solution for you as your jobs need to be templatized
before you can update them by just tweaking the template. You could do this
with some groovy but that has drawbacks if you mess up your groovy.
But Jenkins enterprise has other
:] On Behalf Of teilo
Sent: Tuesday, May 21, 2013 4:03 AM
To: jenkins...@googlegroups.com javascript:
Subject: Mass Jenkins job updates
I use option 4 - Jenkins enterprise
This won't be a drop in solution for you as your jobs need to be
templatized before you can update them by just
to define a default value that all jobs would get?
Bob
*From:* teilo [mailto:teilo+...@teilo.net javascript:]
*Sent:* Tuesday, May 21, 2013 8:59 AM
*To:* jenkins...@googlegroups.com javascript:
*Cc:* Bob Bick
*Subject:* Re: Mass Jenkins job updates
Hi Bob,
Just so
Unfortunately, the above example does not work. Does anyone know if it is
possible to access attribute values in the Groovy template code?
Thanks in advance.
Bob
*From:* teilo [mailto:teilo+...@teilo.net javascript:]
*Sent:* Tuesday, May 21, 2013 9:11 AM
*To:* jenkins
Hi Bob,
I am heavily using CB Enterprise plugins. (Note Folders is not an
enterprise plugin but one of the cloudbees free as-in-beer ones)
I have found most plugins now work. Over the couple of years I have found
some incompatabilities with plugins.
When I have previously found issues
Artifacts/builds will be discarded when any of the conditions are met and the
job is run.
--
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
You could use the xTrigger plugin to monitor the job/lastReleaseBuild url -
which would get changed on release.
On Tuesday, 7 May 2013 17:39:00 UTC+1, Jeff Vincent wrote:
In my dev group we use Jenkins to do the CI portion of our Maven builds
for our team but the company uses Thoughtworks GO
The release process will use the authentication available to the subversion
command line client when run as the user that Jenkins runs as on the slave.
If you have not told the release plugin otherwise it won't pass a user to the
svn client either, so if Jenkins is running as root it will try
spaces in the path (caused by spaces in the job name)?
This is known to cause issues with some flaky maven mojos (although not
used flexmojos...) and would be worthwhile ruling out.
Writing configuration dump to C:\Jenkins\workspace\Common presentation -
On Monday, 18 March 2013 18:44:18 UTC, Tomek Kaczanowski wrote:
Hi James,
thanks for the quick response!
the simplest quick fix is to downgrade Jenkins...
yeah, sure it is
What version did you upgrade from - and what options/parameters are you
using?
1.496
what
the simplest quick fix is to downgrade Jenkins...
What version did you upgrade from - and what options/parameters are you
using?
/James
On Monday, 18 March 2013 16:30:28 UTC, Tomek Kaczanowski wrote:
after upgrading to 1.506 when trying to do a maven release via
Presumably you have Block build when upstream project is building enabled.
If so the reason is that the project has itself marked as an upstream
project.
This could happen if you trigger the job to run itself again (e.g. you want
a continous loop).
Assuming you haven't done that then you need
Presumably the service account under which Jenkins is running does not have
write permissions in the system32 folder.
You may want to add
“-XX:ErrorFile=c:\some\path\where\jenkins\can\write\hs_err_.log” to your
Jenkins JVM startup options so that in the event of a crash the log can be
found.
Fingerprints? https://issues.jenkins-ci.org/browse/JENKINS-13154
That made a significant difference to me.
Other than that google for bandwidth delay product and ssh plugin
(check the last comment in https://issues.jenkins-ci.org/browse/JENKINS-3922)
/James
On Monday, 4 February 2013
Hi,
It’s not supported (which is why the RFE is still open) and comments in the
wiki are not monitored by the plugin maintainer.
Wipe out workspace is probably the best form or release:rollback J
maven won’t delete the tag if it created it anyway - so depending on
what failed you may
Hi all,
Before I embark on some coding, does anyone know if there is such a plugin
that will archive the entire workspace ?
I don't want all the files as attached artifacts - but the workspace as one
big zip/tgz, and ideally be able to only keep it with a different schedule
from the build
Yup - works like a charm :-)
ssh: svcSCM: no address associated with name
fatal: Could not read from remote repository.
That implies to me that it can't find the server calls svcSCM which comes from
your developerConnection in the POM.
have you verified whats in the workspace after a failed
Hi Russ,
To be pretty honest - I would suggest you skip the packaged versions and
use your own init scripts and the war with the inbuilt winstone container.
As for which distro - if you take the above advice it depends on you.
Pretty much anything recent will have a good enough kernel and
On Friday, 25 January 2013 21:56:41 UTC, LesMikesell wrote:
On Fri, Jan 25, 2013 at 3:43 PM, teilo teilo+...@teilo.net javascript:
wrote:
To be pretty honest - I would suggest you skip the packaged versions and
use
your own init scripts and the war with the inbuilt winstone
Hi Chris,
Depending on how you upgraded you can go to
{jenkinsurl}/pluginManager/installed and look at the previously installed
version.
Then if you look on disk in jenkinshome/data/plugins and take a look at the
imestamps on the hpi/jpi files that will tell you when the plugins where
On Friday, 18 January 2013 14:09:07 UTC, Chris Withers wrote:
Depending on how you upgraded you can go to
{jenkinsurl}/pluginManager/installed and look at the previously
installed version.
Where can I find more info on exactly how those downgrade to previous
version buttons work?
I would never advise more than one executor per slave :-o
At some point there will be unit test failures in a project as it has
badly written unit tests that blindly assume they can use port 12345 (and
it will be in use for a different job - and then fight each other). And it
will be the
you may waat to remove the contents of jenkins_dir/data/updates
/James
On Monday, 7 January 2013 13:53:18 UTC, Jon Schewe wrote:
I just switched one of my Jenkins servers to the LTS release. I downloaded
the war file and replaced my current war file. I then updated the update
site for the
/etc/default/jenkins should be your friend on debian.
/James
On Monday, 7 January 2013 21:52:35 UTC, Colin Yates wrote:
Hi all,
I have been running jenkins on Debian for quite a while now, and the
documented way to set the context root to /jenkins was to add a
--prefix=/jenkins to the
There is no way that I currently know of, and the company I work for have
have a need for performance regression tests jobs (so I have looked). I
have not yet had time to open an IDE to look at this.
(we want to look at a rolling average rather than the last successful job,
and also match
Hi Bjørn
As the jenkins user on the slave ssh to the svn server and accept its key.
Depending on your ssh clinet it may override the entry stored in
~/.ssh/known_hosts or may not. (if not then remove the entry manually from
this file and retry with the ssh command)
That should get it
I have completely to opposite experience, native svn+ssh is so much simpler
than all other options!
The provider also says it only works with http/https so may not even be
much use (but then again documentation could just be out of date)
On Friday, 4 January 2013 14:32:35 UTC, domi wrote:
We
if it overrides the entry?
Because it works when I tag it and that is also a commit right?
Thanks,
Bjørn
On Friday, January 4, 2013 3:28:46 PM UTC+1, teilo wrote:
Hi Bjørn
As the jenkins user on the slave ssh to the svn server and accept its
key.
Depending on your ssh clinet it may
:54:09 PM UTC+1, teilo wrote:
Jenkins tags using its inbuilt library (svnkit) as far as I am aware so
the native ssh client doesn't get a look in.
to see if its overridden the entry just check ~/.ssh/known_hosts for an
entry for your server (after you removed it)
What happens
The m2 release plugin supports closing nexus stages for releases. A future
version will support auto dropping or promoting then as well.
*Hello,*
getProject*().*getBuilds*() is returning a list which contains a null entry
which is just not good.*
*This appears on first inspection to be a Jenkins core issue – can you try
with earlier cores to track down when this was introduced?*
* **/James*
On Thursday, 11 October 2012
Downgrading to an earlier lts may not work if the mainline version has changed
any configuration (although it might work as well).
Since I stopped taking the mainline and moved to lts I've found far far fewer
suprises. Downside is you don't see the new experimental stuff so can't provide
You can poll for the existence of a file with the xtrigger plugin but
if one minute isn't satisfactory then you could move the polling into
a job that is always running and doesn't return until the file
exists. Then your script in ftpd creates this trigger file when it
wants the job to be done.
84 matches
Mail list logo
