Unless you're in the habit of manually patching things in plugins, it's
sufficient to backup only the top level files (.jpi/.hpi/.disabled/.pinned).
The folders are just the files extracted for use by Jenkins.
On 29.03.2014, at 00:57, Mishael Kim mish...@gmail.com wrote:
Hi,
I was
I'd try comparing the output of the `env` command in your terminal and in the
Jenkins job to see whether relevant environment variables need to be defined in
the job.
On 29.03.2014, at 05:41, Fatemeh Mehdizadeh mehdizadeh.fate...@gmail.com
wrote:
Hi all,
My test on jenkins is failing
Are you using the Xvnc plugin, or assuming the ability to connect to
another X server? You may find it easier to use the Xvnc plugin and let
Jenkins start and stop an X server for the jobs.
If you're already using the Xvnc plugin, then you might consider checking
that you can connect to the X
Still a newbie, I've moved on to a PC running windows 7 and Java 7. I'm trying
to build the example in the Jenkins Definitive Guide book, and am getting the
below exception. I am able to clone the remote repository from the Git Bash
command line:
git clone
Usually a timeout in calls to git are due to missing credentials
information. In your case, that doesn't seem to be the root problem, since
I can view the contents of that repository without credentials. If you
want to experiment with it, you could create a credential for that github
repository.
And I assume that by just dropping those top level files info a clean
JENKINS_HOME/plugins folder should be sufficient in restoring them all?
On Sat, Mar 29, 2014 at 4:14 AM, Daniel Beck m...@beckweb.net wrote:
Unless you're in the habit of manually patching things in plugins, it's
sufficient
Somewhat related - we've been trying to harden up our Jenkins management
processes and have created a repeatable Jenkins deployment process. We
store some configuration data in our SCM that describes the version of
Jenkins to use, the versions of the plugins and the userContent folder. We
then
Tried the git://github... link, still no luck. Note that it did download
the files to the workspace (C:/.jenkins/workspace), but then the build just
hung and still hasn't finished after 10 minutes. Haven't had time to try
the https link yet.
On Saturday, March 29, 2014 12:09:25 PM UTC-5,
Was the stack trace different on the attempt with the git:// URL? The
stack trace you listed shows that git fetch failed, which would usually
mean that the repository did not complete its download.