On Thursday, November 21, 2013 10:30:03 PM UTC+2, and...@wazoku.com wrote:
Ah yes sorry I missed that..
Now I followed the doc from that page but it still didn't work and left me
in a half-configured state; I had to force a dpkg -i of the old package to
fix it..
Basically it was failing
On 22.11.2013, at 09:27, Marius Gedminas mar...@gedmin.as wrote:
There's a bug in upstream packaging that breaks upgrades:
https://issues.jenkins-ci.org/browse/JENKINS-18798
There's a related bug that makes Jenkins not start up on boot:
https://issues.jenkins-ci.org/browse/JENKINS-19329
I am trying to use the REST API to submit a job and follow it's progress.
The problem that I am facing is that I can not see a fool-proof way to know
what is the job number of the new job when I submit using
job/MyJob/buildWithParameters
What I get back as JSON is designed for the UI but does
+1. We're even considering using Jenkins as the default light scheduler for
some of our customers.
Basically, use Jenkins to do anything repetitive. People's brains should be
used to do things machines can't.
Le 21 nov. 2013 20:59, Mark Waite mark.earl.wa...@gmail.com a écrit :
It is well within
More I don't want you to think I am promising something that I am not. Or
to phrase it another way... it solves a problem that may or may not be your
actual problem... but for sure it is not the problem you originally
asked... but then the problem you originally asked may or may not be your
actual
My results are currently inconsistent with two projects.
In both projects, my maven command line is the same, e.g. clean install
deploy findbugs:findbugs
In one project, Jenkins is picking up the findbugsXml.xml and running
findbugs against it. In the other, no I do not see the FINDBUGS
Hi
Same issue on Windows 7 x64 with jenkins 1.540 and JDK 1.7.0_17.
One solution is downgrade to oldest version like 1.526.
Le jeudi 14 novembre 2013 22:42:53 UTC+1, Benoit Sautel a écrit :
Hello.
I upgraded my Jenkins to the latest version. It is now unable to start. I
get all symptoms
Thanks I'm going to downgrade my git plugin. I think that is what I'm
running into.
On Thursday, November 21, 2013 6:12:33 PM UTC-5, Mark Waite wrote:
You may be suffering from:
An update: it wasn't Jenkins, but a Chef script for
Jenkinshttps://github.com/fnichol/chef-jenkins/blob/317ab1983718559395ac639248b34ab1e4ae5778/recipes/default.rb#L61-L79that
was causing our issue.
*git* was one of the plugins we had configured to automatically upgrade
(the fix was to simply
Nicolas DeLoof just posted a hint that the issue may be related to the
change in the default state of fast remote polling. Fast remote polling
allows the master Jenkins instance to check for changes on a git
repository, without cloning that git repository. That technique makes
commit detection
yes, I'm looking into possible changes in jenkins-core that would allow
such a remote-polling to be used to detect potential changes, then use
workspace to confirm changes actually have to get handled by a build.
2013/11/22 Mark Waite mark.earl.wa...@gmail.com
Nicolas DeLoof just posted a hint
Thanks I'm going to try the Force polling using workspace option.
On Friday, November 22, 2013 11:51:33 AM UTC-5, Nicolas De loof wrote:
yes, I'm looking into possible changes in jenkins-core that would allow
such a remote-polling to be used to detect potential changes, then use
workspace
I just starting using the folders plugin and it looks great. Is there a way
for me to move existing jobs into folders for better organization?
Thanks, Eric
--
You received this message because you are subscribed to the Google Groups
Jenkins Users group.
To unsubscribe from this group and
That should work by moving in filesystem.
(the move feature is part of the Folders Plus plugin that is part of
Jenkins Enterprise offer)
Vincent
2013/11/22 Eric Wood eric.w...@rocketmail.com
The only way I could figure it out was to actually move the job to the
folder in the underlying
There's a (very) new plugin that seems to do exactly what you want:
https://github.com/Spedge/job-run-uuid
https://github.com/jenkinsci/job-run-uuid-plugin
Its developer wrote on the Jenkins devs list:
The plugin allows you to request a build from the API but it returns a JSON
snippet with a
I have set up a bunch of jobs in a folder and linked them as a build pipeline
(i.e. upstream/downstream jobs). The view for the pipeline is also in the
folder. I wanted to be able to better segment my jobs and the pipeline that
controls them. I have noticed that if I set up the pipeline in a
You can manually move jobs from the 'jobs' directory into
'jobs/foldername/jobs'. It will break any existing job relationships, but
plugins should be able to deal with disappearing jobs.
But you should still be able to use the full-featured, closed-source Folders
3.x if you tell Cloudbees your
On 22.11.2013, at 19:09, Eric Wood eric.w...@rocketmail.com wrote:
The triggers for the job work, just linking to the results from the jobs in
the pipeline does not. It seems like a bug and that it would be pretty easy
to fix and would add a lot of value to managing pipeline jobs.
Daniel:
What do you mean by:
But you should still be able to use the full-featured, closed-source Folders
3.x if you tell Cloudbees your email address. The following features exist in
Folders version 3 that have been removed from Folders 4 (and moved into
commercial Folders Plus 2):
How do
On 22.11.2013, at 19:18, Eric Wood eric.w...@rocketmail.com wrote:
How do you gain access to the closed-source version. Is this part of the
CloudBees Free Enterprise Plugins?
Apparently, not anymore. It already includes Folders 4 when I tried it on a
Jenkins 1.532.1-rc. But you can install
Just thought I'd add that 3.15 is a dead end.
It's no problem for me to use it on temporary test instances (and Folders 4 on
the Enterprise-licensed instances), but if, for some reason, Folders 3.x
becomes incompatible with future Jenkins in some way, you'll be in trouble --
upgrading to the
I set up the plugin according
to https://wiki.jenkins-ci.org/display/JENKINS/LDAP+Email+Plugin.
How can I verify that emails from LDAP are being pulled in?
--
You received this message because you are subscribed to the Google Groups
Jenkins Users group.
To unsubscribe from this group and
Thank you for the reply Daniel.
This was a weird issue, that seems to have gone away.
All we did was to leave the Active Directory and Matrix-based security
enable overnight and the next day things began working ok.
Not sure what that is all about.
On Monday, November 18, 2013 9:49:10 AM
Daniel:
I have never performed such an operation. I have installed the Free plugins,
registered with cloudbee and downloaded the 3.15 version. How do I:
upload it to Jenkins via the update center?
On Friday, November 22, 2013 1:36 PM, Daniel Beck m...@beckweb.net wrote:
On 22.11.2013, at
On 22.11.2013, at 20:07, Eric Wood eric.w...@rocketmail.com wrote:
upload it to Jenkins via the update center?
Go to http://yourjenkins/pluginManager/advanced and scroll down to 'Upload
Plugin'.
--
You received this message because you are subscribed to the Google Groups
Jenkins Users
Found how to do it under the advance tab on Manage Plugin, Initially it failed,
but when I restarted jenkins it tells me I have 3.15 installed and 4.0 is
available.
On , Eric Wood eric.w...@rocketmail.com wrote:
Daniel:
I have never performed such an operation. I have installed the Free
Hi jay,
I'm wondering if you ever got a reply to this, or figured out a way to do
this. I'm in the exact same boat. The slave-agent starts just fine and
the Jenkins server can see all the good Node Statistics -- but I don't get
a console log and I create a log.txt as an artifact with
Any updates on this? I'm in the same boat. The slave.jar connects just
fine with no special encoding, but any artifacts created on z/OS USS side
come back to the Jenkins server as EBCDIC and so does the log file found on
the server (even though it won't display on the web page).
Thanks!
It doesn't seem practical for build artifacts to have their encodings changed
automatically; doing so would require that the Jenkins slave code somehow be
told which files are safe to convert and which are not. The log is a different
situation, of course; that would be safe to convert (and to
I agree. I just found the iconv utility. I run this as the last steps in
my shell script on any artifacts I want brought back to Jenkins. This
worked beautifully!
Using Jenkins with z/OS opens up a lot of possibilities!
--
You received this message because you are subscribed to the
I had a similar issue with Tomcat running Jenkins. I was able to get
around it with these Java options:
-Xms64m -Xmx256m
But I also downgraded to Java 6. YMMV.
Dave
--
You received this message because you are subscribed to the Google Groups
Jenkins Users group.
To unsubscribe from
31 matches
Mail list logo
