[00:02:01] *** kutzi has quit IRC
[00:08:45] *** choas has quit IRC
[00:12:59] *** dhackner has quit IRC
[00:15:49] <jenkinsci_builds> Starting build 627 for job jenkins_main_trunk (previous build: SUCCESS)
[00:22:13] <sgronblo> Is deploying supposed to be handled by jenkins? Is it supposed to be its own job? Part of a build-step? A post-build action?
[00:27:42] <jieryn-w> how do you mean deploying?
[00:27:49] *** Lewisham has quit IRC
[00:28:00] <sgronblo> Deploying a web application to a staging server
[00:29:39] <jieryn-w> well, there's a plugin that can assist with that directly: http://wiki.jenkins-ci.org/display/JENKINS/Deploy+Plugin
[00:29:56] <jieryn-w> but if your jenkins job is maven, i prefer to have a custom job which runs cargo:redeploy
[00:30:25] <sgronblo> well this would be for rails projects mostly
[00:31:05] <jieryn-w> how would you do it from the command line? that may be your only option then
[00:31:25] <sgronblo> usually you can basically do cap stagin deploy iirc
[00:31:51] <jieryn-w> so, you have a jenkins freestyle build project ?
[00:31:58] <jieryn-w> just add another step that does  cap stagin deploy  or whatever
[00:33:03] <sgronblo> a build step?
[00:33:30] <jieryn-w> are you using a freestyle build?
[00:33:49] <sgronblo> whats that? just running a shell script?
[00:34:15] <jieryn-w> you're using jenkins? what job type do you use for your project build please?
[00:34:47] <sgronblo> i guess technically the version is still called hudson
[00:34:59] <jieryn-w> ok, what type of job builds your project?
[00:35:07] <jieryn-w> when you created a new job, did you select freestyle ?
[00:35:57] <sgronblo> hmm, i'm not sure atm. i'm at home now, and i've only set up a few jobs at work... don't remember seeing the term freestyle used anywhere though
[00:36:14] <sgronblo> but the build step is configured as a shell script
[00:36:26] <jieryn-w> ok, well, i'm not aware of any custom job types for ruby - but ya never know -- anyway, with freestyle job type you can simple Add Build Step in the /configure
[00:36:40] <jieryn-w> so in that additional build step you'd just invoke the installation mechanism
[00:37:05] <sgronblo> so how come it's not considered a post build action?
[00:37:27] <jieryn-w> i guess i don't see the difference
[00:37:53] <jieryn-w> you seem to always want to do the deployment
[00:39:23] *** abayer has quit IRC
[00:39:49] <sgronblo> well as long as the tests in the build-step pass
[00:40:02] <sgronblo> i guess the term build-step to me is a bit vague
[00:40:49] <sgronblo> and my question isn't so much about how to get it done, but more about what is the right way to do it
[00:41:08] <jieryn-w> those post build steps are all plugins, so you'd need to write a plugin to do your   cap stagin deploy   thing, or i think far more simple would just be to add another build step and check for the existence of the deployable thing
[00:41:37] <jieryn-w> the right way would be to have a proper job type for your programming language :)
[00:43:08] <sgronblo> hmm
[00:43:59] <jieryn-w> but that doesn't seem a likely event, so.. once you've degraded into writing scripts yourself, there's not much use in quarreling over whether it should be two build steps or one
[00:46:22] <sgronblo> i just like doing things in the right way and usually try to bullet proof my decisions
[00:48:04] <jenkinsci_builds> Project jenkins_main_trunk build #627: SUCCESS in 32 min: http://ci.jenkins-ci.org/job/jenkins_main_trunk/627/
[00:48:05] <jenkinsci_builds> * Olivier Lamy: fix link to generated javadoc and add link to test javadoc
[00:48:05] <jenkinsci_builds> * Olivier Lamy: fix test javadoc display name
[00:48:06] <jenkinsci_builds> * Olivier Lamy: oups miss to add this file
[00:48:06] <jenkinsci_builds> * Olivier Lamy: update changelog content
[00:48:39] <jieryn-w> i'm not familiar with capistrano, but it doesn't seem to have any hudson/jenkins integration
[00:48:49] <jieryn-w> so you have to use shell scripts
[00:48:55] <jieryn-w> there's no bullet proof solution for anything
[00:50:02] <sgronblo> well i didnt mean it that seriously, more like if there's a thing called a build step and another thing called a post build action, then it makes me want to put my deployment in the right one of these if possible without too much hassle
[00:52:09] <jieryn-w> i don't use the plugin, but allegedly http://wiki.jenkins-ci.org/display/JENKINS/Batch+Task+Plugin can be utilized to create a shell environment as a post build step
[00:53:42] *** calavera has quit IRC
[00:55:04] *** sshaw has quit IRC
[00:55:09] <sgronblo> ok so that sounds like you could use it to create a "deploy staging" task to run as a post build action and another "deploy production" that you could run manually to deploy when the time is right
[00:56:10] <jieryn-w> i personally think those should be put into separate jobs
[00:56:23] *** Stubbs has quit IRC
[00:57:43] *** elpargo has quit IRC
[00:57:56] <sgronblo> i just think you end up with so many jobs if you have to create at least two jobs for every deployable project
[00:58:27] <jieryn-w> i'm an OO programmer, i prefer modularity and separation of concerns
[00:58:49] <jieryn-w> mucking deployment together with building is technically viable, but .. it is messy
[00:58:57] <sgronblo> well i think that sounds pretty modular
[00:59:05] <jieryn-w> i wish you luck!
[00:59:37] <sgronblo> well it doesnt seem like it would get mucked together if it was a post build action (staging) or a manually activatable task (production)
[00:59:46] <jieryn-w> the build log will be
[01:00:09] <sgronblo> well thats something i havent even thought about
[01:00:10] <jieryn-w> i think building a project and deploying a project are separate aspects
[01:01:11] <jieryn-w> also, if you use security, you no longer can separate who can build the project from who can deploy it
[01:01:25] <jieryn-w> those two groups of people are quite likely not the same
[01:02:08] *** kstreith has quit IRC
[01:02:40] <sgronblo> thats also a good point
[01:03:18] <jieryn-w> i've seen people here using hudson/jenkins going to extraordinary lengths to reduce the # of jobs ... wasting hours, days, weeks ... adding huge amounts of complexity, when all they needed to do was just create another job .. :) you already probably could have done it during this conversation
[01:03:39] <jieryn-w> matrix jobs, build parameterized jobs .... huge complexity
[01:03:58] <sgronblo> well we have mixed implementations atm, some deployments are separate jobs, some are part of a build-step
[01:04:02] <jieryn-w> the times when these jobs are used properly, IMO, is pretty rare :)
[01:04:09] <sgronblo> but i prefer the "one way to do it" philosophy
[01:04:24] <jieryn-w> ok, consistency is important
[01:04:29] <sgronblo> yep
[01:04:36] <jieryn-w> so go one way or the other is better than the mishmash
[01:04:39] <jieryn-w> agreed :)
[01:04:48] <jieryn-w> even if you do it the way i don't prefer, having it that way for all projects is win
[01:06:12] <sgronblo> but isnt there some official specifications for what jenkins considers a build step and so on to be
[01:07:04] *** RSchulzM1 has joined #jenkins
[01:09:26] <jieryn-w> an implementation of Job is a build step, if i'm not mistaken
[01:09:43] <sgronblo> but you can have multiple build steps for a job, right?
[01:10:27] <jieryn-w> it really depends on what job type you created your job with
[01:10:43] <jieryn-w> for maven, there's only one
[01:10:53] <jieryn-w> for freestyle, there are virtually unlimited
[01:10:55] <sgronblo> aha
[01:11:19] <sgronblo> but isnt the maven job type then a special case of job type for which only one build step is allowed?
[01:11:37] <jieryn-w> i really have no insights into your hudson/jenkins deployment :)
[01:11:49] <jieryn-w> whatever job type you used, or whomever used, to create the job .. that is the job type
[01:13:57] *** esteele has joined #jenkins
[01:15:36] *** evilchili has quit IRC
[01:34:48] *** kenneth_reitz has quit IRC
[01:36:01] *** kenneth_reitz has joined #jenkins
[01:37:10] *** kenneth_reitz has quit IRC
[01:37:27] *** vivek_ has joined #jenkins
[01:37:45] *** kenneth_reitz has joined #jenkins
[01:40:23] *** btrim has left #jenkins
[01:50:53] *** joewilliams_away is now known as joewilliams
[01:54:39] *** mconigliaro has quit IRC
[01:58:55] *** joewilliams is now known as joewilliams_away
[01:59:16] *** mindless has quit IRC
[01:59:33] *** kgoess has quit IRC
[02:08:15] *** RSchulzM1 has quit IRC
[02:08:29] *** vjuranek has quit IRC
[02:16:40] *** smolyn has joined #jenkins
[02:22:13] *** RSchulzB has quit IRC
[02:34:41] *** smolyn has quit IRC
[02:34:59] *** kenneth_reitz has quit IRC
[02:55:42] *** BrianFox_ has joined #jenkins
[02:58:40] *** BrianFox has quit IRC
[03:06:38] *** jasonb has quit IRC
[03:07:24] *** vivek_ has quit IRC
[03:08:58] *** jamesd_laptop has joined #jenkins
[03:16:55] *** miclorb has joined #jenkins
[03:24:00] *** jieryn-w has quit IRC
[03:27:15] *** jamesd__ has joined #jenkins
[03:28:41] *** jamesd__ has quit IRC
[03:29:11] *** jamesd__ has joined #jenkins
[03:29:51] *** jamesd_laptop has quit IRC
[03:32:09] *** BrianFox_ has quit IRC
[03:32:17] *** smolyn has joined #jenkins
[03:40:33] *** evilchili has joined #jenkins
[03:40:58] *** rcampbell__ has quit IRC
[03:51:27] *** Haloperidol has quit IRC
[04:03:33] *** joewilliams_away is now known as joewilliams
[04:03:52] *** twood has quit IRC
[04:04:06] *** twood has joined #jenkins
[04:10:09] *** abayer has joined #jenkins
[04:10:09] *** ChanServ sets mode: +o abayer
[04:19:45] *** calculus has quit IRC
[04:22:34] *** bmahe has quit IRC
[04:28:09] *** joewilliams is now known as joewilliams_away
[04:32:01] *** calculus has joined #jenkins
[04:36:46] *** calculus has quit IRC
[04:37:35] *** calculus has joined #jenkins
[04:55:19] *** miclorb has quit IRC
[04:57:10] *** calculus has quit IRC
[05:09:29] *** calculus has joined #jenkins
[05:10:06] *** rakslice|w_ has joined #jenkins
[05:13:24] *** rakslice|w has quit IRC
[05:15:43] *** calculus has quit IRC
[05:15:59] *** calculus has joined #jenkins
[05:22:00] *** afex has quit IRC
[05:23:06] *** lukem has quit IRC
[05:24:15] *** calculus has quit IRC
[05:37:28] *** calculus has joined #jenkins
[05:44:19] *** calculus has quit IRC
[05:50:04] *** calculus has joined #jenkins
[05:55:26] *** calculus has quit IRC
[05:56:36] *** calculus has joined #jenkins
[06:01:04] *** calculus has quit IRC
[06:02:06] *** calculus has joined #jenkins
[06:09:34] *** prusswan has quit IRC
[06:29:08] *** wilmoore has quit IRC
[06:31:24] *** awb has quit IRC
[06:33:44] *** wilmoore has joined #jenkins
[06:38:42] *** andreasmandel has joined #jenkins
[06:38:44] *** sshaw has joined #jenkins
[06:39:48] *** abayer has quit IRC
[06:45:08] *** jasonb has joined #jenkins
[06:46:26] *** ExtraSpice has joined #jenkins
[06:49:05] *** smolyn has quit IRC
[06:57:57] *** jamesd_laptop has joined #jenkins
[07:01:44] *** jamesd__ has quit IRC
[07:05:51] *** __edorian has quit IRC
[07:11:04] *** abayer has joined #jenkins
[07:11:05] *** ChanServ sets mode: +o abayer
[07:42:36] *** awb has joined #jenkins
[07:46:26] *** rakslice has joined #jenkins
[07:49:25] *** aheritier has joined #jenkins
[07:49:25] *** ChanServ sets mode: +v aheritier
[07:50:37] *** awb has quit IRC
[07:57:14] *** awb has joined #jenkins
[08:19:40] *** joewilliams_away is now known as joewilliams
[08:24:59] *** awb has quit IRC
[08:35:45] *** mig5 has left #jenkins
[08:47:01] *** aheritier has quit IRC
[08:47:16] *** protocol7 has joined #jenkins
[09:02:40] *** _marc` has joined #jenkins
[09:15:24] *** jamespage has quit IRC
[09:27:23] *** andreasmandel has quit IRC
[09:27:55] *** sshaw has quit IRC
[09:31:40] *** joewilliams is now known as joewilliams_away
[09:34:21] *** choas has joined #jenkins
[09:39:17] *** redsolo has quit IRC
[09:39:26] *** redsolo has joined #jenkins
[09:39:26] *** ChanServ sets mode: +v redsolo
[09:58:59] *** d2m has joined #jenkins
[10:09:50] *** Espen-_- has joined #jenkins
[10:10:46] *** cristiano has joined #jenkins
[10:12:21] *** hekman_ has joined #jenkins
[10:16:03] *** esteele_ has joined #jenkins
[10:16:06] *** LiohAu has joined #jenkins
[10:16:22] *** abayer has quit IRC
[10:16:22] *** esteele has quit IRC
[10:16:23] *** Creeture has quit IRC
[10:16:23] *** soren has quit IRC
[10:16:23] *** vila has quit IRC
[10:16:24] *** ZubZero has quit IRC
[10:16:25] *** hekman has quit IRC
[10:16:25] *** krag0th has quit IRC
[10:16:26] *** esteele_ is now known as esteele
[10:16:27] *** abayer1 has joined #jenkins
[10:16:27] *** abayer1 is now known as abayer
[10:16:28] *** ChanServ sets mode: +o abayer
[10:17:36] <LiohAu> hi
[10:18:12] *** stisti has quit IRC
[10:18:49] <LiohAu> can anybody explain me the ssh keys part to add a slave ?
[10:20:10] *** soren has joined #jenkins
[10:21:27] <LiohAu> the field is named "Private Key File", and i thought the master needed the public key (and not the private) to SSH on the slave, but it seems i didn't understand this part
[10:23:34] *** vila has joined #jenkins
[10:30:09] *** esteele has quit IRC
[10:42:02] <rakslice> LiohAu: You have a key pair on the master that it will use to authenticate; you put the public key into the ~/.ssh/authorized_keys file on the slave and put the name of that private key file in the field
[10:42:26] <LiohAu> so i run the ssh-keygen on the master ?
[10:42:31] <rakslice> yup
[10:42:38] <LiohAu> and i have to be logged as my jenkins user ?
[10:43:47] <rakslice> that's the easiest (jenkins will need to have permission to read the private key file)
[10:44:23] <LiohAu> ok i did the exact opposite, that's why it didn't work
[10:44:25] <LiohAu> ^^
[10:46:41] <LiohAu> btw do you know which is one is better ? use dsa or rsa (for the key) ?
[10:47:08] <rakslice> dsa is newer
[10:49:27] <LiohAu> ok
[10:51:13] *** jamesd2 has joined #jenkins
[10:51:24] *** jamesd_laptop has quit IRC
[10:52:27] *** kutzi has joined #jenkins
[10:52:28] *** ChanServ sets mode: +v kutzi
[10:56:32] <LiohAu> YOUHOU! 1 week after i finally have a slave working :(
[11:02:21] *** jamesd2 has quit IRC
[11:02:59] *** Stubbs has joined #jenkins
[11:04:31] *** Stubbs has quit IRC
[11:10:33] *** andreasmandel has joined #jenkins
[11:11:50] <kutzi> olamy FYI: delete the branch locally the do do git push origin :branchname to delete a remote branch
[11:12:11] <kutzi> I love stackoverflow http://stackoverflow.com/questions/2895906/cannot-delete-a-remote-branch-created-unintentionally
[11:24:16] <LiohAu> anybody has an advice on which SSO can i use (or should i use) with jenkins ?
[11:26:24] *** andreasmandel has quit IRC
[12:05:17] *** wilmoore has quit IRC
[12:32:38] *** vjuranek has joined #jenkins
[13:07:43] *** ExtraSpice has quit IRC
[13:09:35] *** jamesd_laptop has joined #jenkins
[13:21:40] *** ExtraSpice has joined #jenkins
[13:30:48] <jenkinsci_builds> Starting build 628 for job jenkins_main_trunk (previous build: SUCCESS)
[13:37:22] *** resmo_ has joined #jenkins
[13:38:20] *** magnayn has joined #jenkins
[13:38:20] *** ChanServ sets mode: +v magnayn
[13:39:47] *** resmo has quit IRC
[13:43:55] *** LiohAu has quit IRC
[13:43:58] *** fcamblor has joined #jenkins
[13:44:18] *** ChanServ sets mode: +v fcamblor
[13:57:54] *** kutzi has quit IRC
[13:59:25] *** richardm55 has joined #jenkins
[14:04:16] <jenkinsci_builds> Project jenkins_main_trunk build #628: SUCCESS in 33 min: http://ci.jenkins-ci.org/job/jenkins_main_trunk/628/
[14:04:17] <jenkinsci_builds> Christoph Kutzinski: [JENKINS-7535] don't remember per-moduleset modules to prevent OOMEs
[14:18:27] *** Haloperidol has joined #jenkins
[14:20:38] *** prusswan has joined #jenkins
[14:26:43] *** olamy has quit IRC
[14:28:25] *** calculus has quit IRC
[14:37:01] *** calculus has joined #jenkins
[14:43:19] *** calculus has quit IRC
[14:43:33] *** calculus has joined #jenkins
[14:43:48] *** olamy has joined #jenkins
[14:43:48] *** ChanServ sets mode: +v olamy
[14:50:22] *** olamy has quit IRC
[14:51:28] *** calculus has quit IRC
[14:52:15] *** calculus has joined #jenkins
[14:56:36] *** calculus has quit IRC
[15:00:48] <jenkinsci_builds> Starting build 629 for job jenkins_main_trunk (previous build: SUCCESS)
[15:02:37] *** calculus has joined #jenkins
[15:04:56] *** RSchulzB has joined #jenkins
[15:06:26] *** RSchulzM1 has joined #jenkins
[15:07:02] *** calculus has quit IRC
[15:09:37] *** evilchili has quit IRC
[15:10:07] *** evilchili has joined #jenkins
[15:12:11] *** kutzi has joined #jenkins
[15:12:11] *** ChanServ sets mode: +v kutzi
[15:15:59] *** kutzi has quit IRC
[15:17:12] *** cristhiank has joined #jenkins
[15:30:57] *** jamesd_laptop has quit IRC
[15:31:24] *** jamesd_laptop has joined #jenkins
[15:31:31] *** calculus has joined #jenkins
[15:33:14] *** jamesd_laptop has quit IRC
[15:33:40] *** jamesd_laptop has joined #jenkins
[15:34:09] <jenkinsci_builds> Project jenkins_main_trunk build #629: SUCCESS in 33 min: http://ci.jenkins-ci.org/job/jenkins_main_trunk/629/
[15:34:10] <jenkinsci_builds> wyukawa: fix url link to Japanese Ant Document of Ant glob-Syntax
[15:34:51] *** jamesd_laptop has quit IRC
[15:35:20] *** jamesd_laptop has joined #jenkins
[15:35:52] *** calculus has quit IRC
[15:36:52] *** vivek_ has joined #jenkins
[15:38:40] *** andreasmandel has joined #jenkins
[15:41:41] *** calculus has joined #jenkins
[15:52:54] *** cristhiank_ has joined #jenkins
[15:56:12] *** cristhiank has quit IRC
[15:58:12] *** Stubbs has joined #jenkins
[16:06:32] *** andreasmandel has quit IRC
[16:10:12] *** rcampbell__ has joined #jenkins
[16:20:06] *** akostadinov has joined #jenkins
[16:22:13] *** LiohAu has joined #jenkins
[16:24:39] *** mdd has joined #jenkins
[16:25:39] <mdd> anyone around that played with xcode 4, ios projects and workspaces? it seems I'm not able to specify the directory for "Publish JUnit test result report"
[16:28:12] <mdd> problem is that the build results are not placed in a directory relative to workspace (as in jenkin's workspaces), but somewhere below ~/Library/Developer/Xcode/DerivedData/<ProjectName>-<UDID>/...
[16:31:00] *** Stubbs has quit IRC
[16:44:34] *** andreasmandel has joined #jenkins
[16:55:25] *** nd___ has joined #jenkins
[16:56:27] *** awb has joined #jenkins
[16:57:23] <mdd> got it, made my run tests target copy the results to the workspace dir (instead of keeping it in the build-dir)
[16:58:12] *** nd__ has quit IRC
[16:59:11] *** Haloperidol has quit IRC
[16:59:46] *** andreasmandel1 has joined #jenkins
[17:02:31] *** vjuranek has quit IRC
[17:02:37] *** vjuranek has joined #jenkins
[17:03:18] *** andreasmandel has quit IRC
[17:07:12] *** vjuranek has quit IRC
[17:07:26] *** vjuranek has joined #jenkins
[17:20:29] *** joewilliams_away is now known as joewilliams
[17:27:05] *** andreasmandel1 has quit IRC
[17:28:59] *** kutzi has joined #jenkins
[17:29:05] *** ChanServ sets mode: +v kutzi
[17:31:30] *** aeris- has joined #jenkins
[17:32:02] *** smolyn has joined #jenkins
[17:36:10] *** d2m has quit IRC
[17:38:19] *** aeris- is now known as _Aeris_
[17:41:24] *** awb has quit IRC
[17:42:56] *** Haloperidol has joined #jenkins
[17:47:24] *** vjuranek has quit IRC
[17:48:42] *** smolyn has quit IRC
[17:50:52] *** d2m has joined #jenkins
[17:56:06] *** magnayn has quit IRC
[18:08:57] *** olamy has joined #jenkins
[18:09:05] *** ChanServ sets mode: +v olamy
[18:14:05] *** Mick has joined #jenkins
[18:14:11] *** smolyn has joined #jenkins
[18:14:31] *** Mick is now known as Guest25641
[18:15:36] <Guest25641> Hi friends, I am having an issue with the Git plugin on Jenkins, it drops connection if the repo is large
[18:15:57] <Guest25641> I have already posted it once on the maiing list without much help, so where can i get more help on the issue?
[18:18:06] <Guest25641> @kohsuke please help....
[18:19:22] *** akostadinov has quit IRC
[18:20:11] *** joewilliams is now known as joewilliams_away
[18:23:08] <kohsuke> @Guest25641 but git checkout is done by the git(1). My initial reaction is that I'm not sure how Jenkins could be responsible
[18:24:58] <Guest25641> @kohsuke but it works fine when done frm git bash or Tortoise Git or even windows command prompt, only its not working within Jenkins, so probably an issue with the Git plugin in Jenkins
[18:25:50] <Guest25641> @kohsuke and as a first step its not doing git checkout, its doing git clone -o origin <repo> where it fails and drops the connection
[18:26:21] <kohsuke> Yeah, that's really what I'm saying. It's the git command that's failing, right?
[18:26:48] <Guest25641> @kohsuke only within Jenkins, when the same command is copy-pasted into Git bash it works fine
[18:26:58] <selckin> define drops the connections
[18:27:35] <Guest25641> you can see the  complete trace log here which defines drops the connection -  http://jenkins.361315.n4.nabble.com/Potential-curl-keep-alive-bug-in-Jenkins-td3382090.html
[18:27:58] *** edorian has joined #jenkins
[18:28:11] *** kutzi8175 has joined #jenkins
[18:28:57] <Guest25641> I have ran out of all options and you guys are my last hope :(
[18:29:06] *** stisti has joined #jenkins
[18:29:10] <selckin> git doesn't like http protocol in general
[18:29:45] <Guest25641> but it's not git, because Tortoise git and git bash can easily clone that repo over http from the same server
[18:30:00] <selckin> just saying if you're desprate
[18:30:23] <_Aeris_> what is your jenkins OS?
[18:30:34] <Guest25641> Windows 2003 standard Ed.
[18:30:41] <kohsuke> I think comparing the difference in the HTTP requests/responses was a good way to isolate the problem.
[18:30:46] <_Aeris_> git on windows is a very mess?
[18:30:49] <Guest25641> I have tried both msysgit and even compiled git on cygwin, same results
[18:31:05] <_Aeris_> tortoise git and git bash use cygwin
[18:31:15] <Guest25641> again its not git, if it was git how wud Tortoise Git, Git bash and command line work fine ...
[18:31:42] <selckin> did you try the same command as jenkins in git bash?
[18:31:47] <_Aeris_> but on windows, git tortoise or git bash is not git
[18:32:10] <_Aeris_> because of many many hack to be able to run git on win
[18:32:20] <Guest25641> @kohsuke Yes sir, I compared the differences andin both cases they look identically equal with the GIT_TRACE and GIT_CURL_VERBOSE enabled
[18:32:29] <kohsuke> Sounds like the next step you want is to compare if the HTTP requests made by git is different when invoked from Jenkins.
[18:33:12] <kohsuke> I suppose the hypothesis you are after is that when run in Jenkins the environment is different and that causes some behaviour change, right?
[18:33:18] <Guest25641> @Aeris Tortoise Git allows you to pick up the git installation you want to choose, it does not comes pre-packaged with Git
[18:33:33] <_Aeris_> yes Guest25641
[18:33:47] <_Aeris_> but even with tortoise, there is hack
[18:33:55] <_Aeris_> git is not native on win
[18:34:24] <Guest25641> @kohsuke Yes, my assumption here is that the git plugin in jenkins is not fetching the fetch-packs correctly, its dropping the connection earlier then its required or its something to do with the connection: keep-alive
[18:34:26] <_Aeris_> even this is git.exe, this is not strictly equivalent to git(1)
[18:34:54] <_Aeris_> because of cygwin or other tricks
[18:35:11] <kohsuke> Guest25641: just to make sure so we are on the same page, all Jenkins does is to run git(1) as the child process.
[18:35:29] <_Aeris_> kohsuke > even on win?
[18:35:29] <kohsuke> So when you say "it's dropping the connection earlier", it really means "git forked from Jenkins is dropping the connection earlier"
[18:35:38] <kohsuke> Yes. It demands git.exe
[18:35:42] <_Aeris_> ok
[18:36:37] <Guest25641> @kohsuke so is it possible to debug the jenkins-Git forked process and the error code or response that Git passes back to jenkins
[18:36:44] <selckin> and it's the server closing the connection anyway no?
[18:36:54] <_Aeris_> Guest25641 > use wireshark
[18:37:06] <kohsuke> Yeah, +1 for wireshark
[18:37:14] <Guest25641> @Aeris Yes, I have installed wireshark today, will sniff the packets
[18:37:19] <_Aeris_> even if windows has no loopback?
[18:37:32] *** akostadinov has joined #jenkins
[18:37:43] <kohsuke> And "Connection: close" just means "let's terminate this TCP socket after we are done with this HTTP response"
[18:37:49] *** Amanda has joined #jenkins
[18:37:54] <kohsuke> It doesn't mean "Houston we have a problem, connection terminated right away"
[18:37:58] <_Aeris_> ^^
[18:38:21] <prusswan> have you attempted to setup the jenkins/job on another windows env?
[18:38:25] <Guest25641> @kohsuke what does this mean: * transfer closed with outstanding read data remaining
[18:38:48] <Guest25641> I have setup 2 win 2003 computers - one with jenkins, one with hudson - same behaviour
[18:39:02] <kohsuke> That's coming from Git. So I'm not entirely sure
[18:39:07] <Guest25641> why is the transfer closed when there's still data to be read
[18:39:11] <prusswan> if your repo is not private, I can attempt to replicate your job on my xp64 machine
[18:39:28] <_Aeris_> it's not new that git is not windows production ready
[18:39:37] <Guest25641> @prusswan i am sorry, but its highly secured repo, cannot share
[18:39:54] 
[18:40:02] <Guest25641> i even tried older versions of Git i.e. 1.7.3.1 but same results
[18:40:11] <prusswan> I see, but it would be good if you can narrow down the variables on another windows
[18:40:24] <prusswan> if you are lucky maybe it is just on ws2k3
[18:40:24] <kohsuke> Guest25641, If I were you, I'd really try different transport, as selckin suggested
[18:40:55] <Guest25641> @prusswan I was running jenkins in tomcat over apache, i narrowed it down to just jenkins, removed tomcat and apache, so really runnin out of options
[18:40:59] 
[18:41:03] <_Aeris_> Guest25641 > do you try another http git repo?
[18:41:19] <_Aeris_> for example a github one?
[18:41:35] <Guest25641> @Aeris Yes smaller repos on the same server work fine, its only this >5GB repo packs when it fails
[18:41:39] <prusswan> is switching OS an option?
[18:41:52] <_Aeris_> 5GB?
[18:41:55] <_Aeris_> Oo
[18:42:06] <Guest25641> @prusswan yes now i will try all the options you guys said - shifting O.S, wireshark etc
[18:42:10] <selckin> does you os support files bigger then 2gb? ;)
[18:42:17] <_Aeris_> what is the remote OS?
[18:42:27] <prusswan> if you do, linux is the safest
[18:42:28] <_Aeris_> and your local fs?
[18:42:50] <kohsuke> You could dig deep enough with Wireshark etc. and understand where things are going wrong, but in terms of getting it going, I think it's much faster to switch the protocol.
[18:42:51] <Guest25641> it's weekend and I really want to get it going by monday..remote OS is linux, i asked the system admins to check the server logs, and they said all looks gud on httpd logs
[18:43:03] <prusswan> fat32 limit is 4G....so if there's a need to create some temp file >4G...
[18:43:30] <Guest25641> @kohsuke yes we have http:// and git@ssh, we don't have git://, so will try git@ssh now..
[18:43:50] <_Aeris_> or temporary files could fill up temporary space too
[18:43:54] <Guest25641> @prusswan that's a very good point, one other Git anallyst said something similar
[18:44:08] <Guest25641> do you think its the 4G limit that cud be causing this issue
[18:44:17] <_Aeris_> yes it could
[18:44:32] <kohsuke> Hearing that it happens only with big repository, another possibility is that the server is cutting off connection because it thinks the connection is stalled.
[18:44:39] <_Aeris_> if you are on fat32 and one file grows to 4Gb
[18:44:41] <Guest25641> @Aeris so how to increase that limit?
[18:44:49] <_Aeris_> connection suddently close
[18:44:57] <_Aeris_> Guest25641 > ext4?
[18:44:58] <prusswan> on windows you need a parition with ntfs
[18:44:59] <_Aeris_> =)
[18:44:59] <kohsuke> Most web server is very intolerant of slow fetching clients.
[18:45:02] <_Aeris_> or ntfs
[18:45:28] <prusswan> linux should not have such a problem iirc
[18:45:30] <kohsuke> But does Git actually create a single humongous file?
[18:46:06] <_Aeris_> perhaps a temporary one
[18:46:07] <Guest25641> @prusswan Yes, it makes me believe that it's the 4G fat32 limit, i have to try linux for sure now...
[18:46:10] <prusswan> is there any well known git repo that's that big even?
[18:46:19] *** akostadinov has quit IRC
[18:46:21] <prusswan> i don't mind testing this if possible
[18:46:35] <Guest25641> what about the linux kernel...is it not 4g?
[18:46:41] <_Aeris_> no
[18:46:48] <_Aeris_> less than 1Gb
[18:46:53] <selckin> it's only fat32, you can convert to ntfs
[18:46:56] *** akostadinov has joined #jenkins
[18:47:00] <selckin> which you should be using anyway
[18:47:05] <selckin> if thats the problem
[18:47:07] <kohsuke> http://git.661346.n2.nabble.com/Large-pack-causes-git-clone-failures-what-to-do-td5481488.html
[18:47:40] <kohsuke> You are right. Shawn says git clone doesn't split its pack
[18:47:52] <kohsuke> If the server sends you a single 5GB pack and you are on FAT32...
[18:48:17] <prusswan> it's a simple matter to resolve, just slap on more space :)
[18:48:19] <kohsuke> Hmm, but then that doesn't explain why it doesn't fail on git from CLI
[18:48:27] <kohsuke> I mean from shell.
[18:48:46] <Guest25641> @kohsuke  exactly it should fail on all the clients in that case
[18:49:09] <selckin> there is a dumb and "smart" http protocol
[18:49:13] <selckin> the latter is kinda new
[18:49:19] *** andreasmandel has joined #jenkins
[18:49:23] <_Aeris_> kohsuke > seems better to store data and then process them
[18:49:35] <Guest25641> i believe all 1.7.4+ version comes with smart_http enabled by default
[18:49:41] <_Aeris_> in case of errors, this is much secured
[18:49:48] <selckin> normally with git over http, it can't create deltas and send you just what you need etc, which is better with the new smart one
[18:54:36] *** echelog-1 has joined #jenkins
[18:55:07] <_Aeris_> prusswan > with fat, it will fail at 4Gb in all cases
[18:55:09] <Guest25641> @prusswan It could be a memory issue as well as the server has just 2GB of ram but again how come tortoise git, git bash etc can make it work in the same ecosystem and not jenkins
[18:55:14] <_Aeris_> even with more memory
[18:55:20] *** morgajel has joined #jenkins
[18:55:24] <prusswan> _Aeris: yes i understand that
[18:55:46] *** akostadinov has joined #jenkins
[18:56:15] <kohsuke> Your server is Windows 2003, you said?
[18:56:22] <kohsuke> And Jenkins is installed as a service, I assume.
[18:56:31] <Guest25641> Yes, Win 2003 Std. Edition - 32 bit OS
[18:56:53] <kohsuke> (how come you have FAT32 and NTFS on Windows 2003 is bit of a mystery to me)
[18:56:58] <Guest25641> no jenkins is installed under the tomcat container, which is started as a service
[18:57:20] *** akostadinov has quit IRC
[18:57:26] <Guest25641> @kohsuke what you mean FAT32 and NTFS on Win 2003, I never said I had them...
[18:57:27] <kohsuke> You might want to try running a command prompt of the service user account to make the environment match more closely
[18:57:38] <_Aeris_> (Guest25641 > kernel git is 391.75 MiB)
[18:57:50] <kohsuke> See http://wiki.jenkins-ci.org/display/JENKINS/How+to+get+command+prompt+as+the+SYSTEM+user
[18:58:14] <Guest25641> @kohsuke hold on, let me vpn in to get the info again
[18:58:20] <kohsuke> Guest25641: oh, because a lot of conversations here were based on the FAT32 4GB limit.
[18:58:45] <selckin> kinda says everything that he still hasn't check that
[18:58:48] <kohsuke> "FAT32 and NTFS" -> "FAT32 and not NTFS". sorry.
[18:59:02] <prusswan> kohsuke: is the service user account also used when tomcat is started not as a service?
[18:59:17] <kohsuke> That depends on how his Tomcat is set up
[18:59:29] <kohsuke> It's very easy to check which user account runs which process, even on Windows.
[18:59:31] <Guest25641> @prusswan yes i changed the service account to start under the same user account to use the same SSH keys
[19:00:08] <prusswan> kohsuke: because i gave up on the service route due to complications with other dependencies i need, in the end im using the good old startup.bat
[19:01:18] <kohsuke> prusswan: one pain that I know of is tests/tools that require GUI, and another is network drives
[19:01:44] <kohsuke> Guest25641: and this is another check list: http://wiki.jenkins-ci.org/display/JENKINS/My+software+builds+on+my+computer+but+not+on+Jenkins
[19:02:45] <prusswan> kohsuke: in my instance was that im using pageant to auto-load the keys, and i could never get jenkins in tomcat (service) to detect the keys properly...even with known workarounds to setup pageant as a service
[19:03:55] *** akostadinov has joined #jenkins
[19:04:55] *** akostadinov has quit IRC
[19:05:33] *** akostadinov has joined #jenkins
[19:06:56] <kohsuke> It's good that there's always an escape hatch that is a startup script
[19:07:51] *** akostadinov has quit IRC
[19:08:25] *** akostadinov has joined #jenkins
[19:09:00] *** akostadinov has quit IRC
[19:09:23] <_Aeris_> windows is not a world for developpers =)
[19:09:30] *** akostadinov has joined #jenkins
[19:09:52] <_Aeris_> very simple tasks could be a real pain?
[19:11:03] <Guest25641> @Aeris unfortunately not my call
[19:11:05] *** akostadinov has quit IRC
[19:11:47] *** akostadinov has joined #jenkins
[19:14:52] *** akostadinov has quit IRC
[19:17:04] *** akostadinov has joined #jenkins
[19:17:20] *** akostadinov has quit IRC
[19:18:03] *** akostadinov has joined #jenkins
[19:20:49] <Guest25641> @all Just checked, the filesystem is NTFS
[19:21:09] *** akostadinov has quit IRC
[19:21:41] *** akostadinov has joined #jenkins
[19:23:46] *** akostadinov has joined #jenkins
[19:26:59] *** choas has quit IRC
[19:28:05] *** cowmix has quit IRC
[19:33:19] *** stisti has quit IRC
[19:37:24] <prusswan> @Guest25641 are you able to replicate the command that actually causes the drop? even as the system user?
[19:38:34] <Guest25641> @prusswan what you mean? I give the http://repo_url in my jenkins job and it makes the call git clone -o origin <repo> <workspace> and fails
[19:39:46] <Guest25641> git clone --progress -v repo workspace, so i wish the git plugin in hudson allowed the user to pass that option
[19:40:04] <prusswan> as it you can execute it in command prompt, and it drops
[19:40:25] <Guest25641> when i give the same command in git bash or cmd prompt it works, one thing i noticed in tortoise git is that it's passing the '--progress' option i.e.
[19:40:25] <Guest25641> no, it works fine in git bash, command prompt and tortoise git, drops only when done within jenkins
[19:41:32] <prusswan> how about cmd prompt as the same user jenkins is running as? i.e. system?
[19:42:03] <Guest25641> yes, i right clicked command prompt and explictily specified the same user which is running tomcat under which jenkins in running
[19:42:25] <prusswan> no, it is not good enough
[19:42:55] <prusswan> did you do something like: http://wiki.jenkins-ci.org/display/JENKINS/How+to+get+command+prompt+as+the+SYSTEM+user
[19:46:33] *** Guest25641 has quit IRC
[19:51:31] *** Mick99 has joined #jenkins
[19:51:44] <Mick99> @prusswan hi, i am sorry, got dc
[19:51:54] <Mick99> no, i was not using it that way
[19:52:48] <Mick99> Mick99 <-- same guy who's experiencing some issues with jenkins, was under the id guest45xxx
[19:54:33] <mwalling_> Guest25641, but close
[19:54:34] <mwalling_> :)
[19:54:37] <prusswan> then you should do that...to find out what exactly was jenkins doing
[19:54:52] <Mick99> okay trying that now...
[19:56:55] <Mick99> one more thing, before i try that, when i do 'git branch -a' i see lots of branches like
[19:57:17] <Mick99> remotes/origin/HEAD -> origin/master
[19:57:33] <Mick99> remotes/origin/branch_1
[19:57:41] <Mick99> remotes/origin/master
[19:57:53] <Mick99> remotes/origin/master_28d2c222
[19:58:00] <Mick99> remotes/origin/branch_2
[19:58:02] <Mick99> remotes/origin/branch_3
[19:58:21] <Mick99> remotes/origin/b_master
[19:58:38] <Mick99> so in the jenkins job, shud i specify any branch or should i leave it black i.e. **
[19:59:22] <prusswan> I don't think it should matter...but what do I really know about a humongous git repo :)
[20:00:23] <Mick99> yah, its humongous - 10-12 yrs of code :)
[20:01:05] *** cristiano has quit IRC
[20:05:44] *** vivek_ has quit IRC
[20:17:57] *** wilmoore has joined #jenkins
[20:18:38] *** kutzi8175 has quit IRC
[20:22:20] *** edorian has quit IRC
[20:33:52] *** stisti has joined #jenkins
[20:38:51] *** larrys has quit IRC
[20:45:01] *** esteele has joined #jenkins
[20:45:14] *** Stubbs has joined #jenkins
[20:51:29] *** RSchulzM1 has quit IRC
[20:53:04] *** awb has joined #jenkins
[20:56:04] *** RSchulzM1 has joined #jenkins
[21:04:45] *** d2m has quit IRC
[21:04:50] <kutzi> jenkins-admin: create   project-stats-plugin on github for mambu
[21:04:51] <jenkins-admin> I didn't understand the command
[21:05:21] <kutzi> jenkins-admin: Create  project-stats-plugin on github for mambu
[21:05:22] <jenkins-admin> I didn't understand the command
[21:07:05] <kutzi> jenkins-admin: create  project-stats-plugin on github for mambu
[21:07:06] <jenkins-admin> I didn't understand the command
[21:07:09] <kutzi> hmm
[21:08:49] <kutzi> abayer: you know what I'm doing wrong?
[21:10:26] *** smolyn has quit IRC
[21:12:20] *** rcampbell_ has joined #jenkins
[21:13:05] <kutzi> rtyler?
[21:14:27] *** rcampbell__ has quit IRC
[21:15:11] *** joewilliams_away is now known as joewilliams
[21:20:58] <mwalling_> two spaces after create
[21:21:51] <Mick99> @prusswan I tried what you suggested but same result, works in command prompt, not in jenkins
[21:24:33] <kutzi> mwalling_ yes but only on the 1st try
[21:24:53] <mwalling_> kutzi: the first try you had 3 spaces
[21:25:18] <kutzi> jenkins-admin: create project-stats-plugin on github for mambu
[21:25:45] <mwalling_> great, i got you to break the bot :(
[21:25:57] <jenkins-admin> New github repository created at https://github.com/jenkinsci/project-stats-plugin
[21:26:03] <kutzi> nope :)
[21:26:21] <kutzi> thanks, I didn't see the second space
[21:26:38] <mwalling_> stupid regex not being " +" :)
[21:26:42] <kutzi> I guess the bot could be a little more error tolreant
[21:26:49] <kutzi> yes .)
[21:27:08] <_Aeris_> regexp is evil
[21:27:10] <_Aeris_> =)
[21:27:22] <mwalling_> regex > .*
[21:31:03] *** Mick99 has quit IRC
[21:31:32] <Haloperidol> guys the link to the turial still has hudson in it and also the title of that page is called Hudson Tutorials
[21:31:48] <Haloperidol> *tutorial
[21:33:40] <olamy> doh I don't have karma to push here https://github.com/jenkinsci/pom
[21:36:09] *** rcampbell_ has quit IRC
[21:36:41] *** rcampbell_ has joined #jenkins
[21:40:18] *** Mick99 has joined #jenkins
[21:41:31] <Mick99> @kohsuke @_Aeris_ @prusswan @elckin :okay as you suggested, i used wireshark and analyzed the data and here's the difference i see:
[21:42:49] <Mick99> jenkins: 00xxx725 multi_ack_detailed.side-band-64k-thin-pack-no-progress.ofs-delta
[21:42:51] *** rcampbell_ has quit IRC
[21:43:15] <Mick99> command prompt: 3838xxx883 jenkins: 00xxx725 multi_ack_detailed.side-band-64k-thin-pack.ofs-delta
[21:43:48] <Mick99> so as you can see Jenkins sends a 'no-progress' which command prompt does not
[21:45:45] <_Aeris_>        --progress
[21:45:45] <_Aeris_>            Progress status is reported on the standard error stream by default when it is attached to a terminal, unless -q is specified. This flag forces progress status even if the standard error stream is not directed to a terminal.
[21:46:09] <_Aeris_> seems strange this feature fails cloning?
[21:46:19] *** LiohAu has quit IRC
[21:46:50] <_Aeris_> do you
[21:46:54] <_Aeris_> ><
[21:47:06] *** LiohAu has joined #jenkins
[21:47:19] <Mick99> wats >< ?
[21:47:21] <_Aeris_> do you clone with progress arg in command line?
[21:48:03] <Mick99> no i copy the exact same command from jenkins that failed and paste it in the command line, here's the exact command
[21:48:58] <Mick99> C:/git/bin/git.exe clone =o origin <repo_url> <workspace>
[21:51:12] *** LiohAu has quit IRC
[21:51:42] *** protocol7 has quit IRC
[21:51:47] <_Aeris_> Mick99 > is the cloning process stop immediatly or after a while?
[21:52:03] <Mick99> stops after 4-5 mins, takes a while
[21:52:42] *** protocol7 has joined #jenkins
[21:53:28] <_Aeris_> IMO, your problem is due to your repo size
[21:53:48] <_Aeris_> 5Gb of data, this is very very huge
[21:53:52] <Mick99> trace clearly shows that the --no-progress is being set internally i.e. trace: run_command: 'fetch-pack' '--stateless-rpc' '--lock-pack' '-- thin' '--no-progress'
[21:54:13] <_Aeris_> and imo clues of very bad practices of scm
[21:55:49] <kutzi> why are 5 GB of repo size a clue of bad scm practice?
[21:56:18] *** rcampbell_ has joined #jenkins
[21:57:01] <_Aeris_> even huge project li
[21:57:17] <_Aeris_> like linux is less than 500Mb
[21:57:42] *** ExtraSpice has quit IRC
[21:57:50] <_Aeris_> 392Mb exactly
[21:58:03] <_Aeris_> rails is 30Mb
[21:58:31] <_Aeris_> 5Gb is too much
[21:58:33] <kutzi> okay, but there are even bigger projects than linux possibly
[21:58:43] <_Aeris_> and lead to a lot of problem
[21:58:52] *** andreasmandel1 has joined #jenkins
[21:59:06] <kutzi> but then they should be modularized into multiple repos, probably. Yeah, think I got your point
[21:59:16] 
[21:59:56] <kutzi> I think frequent commits and therefore an increasing repo size are more a sign of good scm practice
[22:00:04] 
[22:00:13] <_Aeris_> and more than 100 branches
[22:00:36] <_Aeris_> increasing size of repos is not the clue
[22:00:48] <_Aeris_> increasing a lot yes
[22:01:15] <_Aeris_> Mick99 > how many commits in your repo?
[22:01:22] <_Aeris_> and branches?
[22:01:43] *** andreasmandel has quit IRC
[22:01:59] <Mick99> we are moving from a different scm to git, has over 10-12 yrs of code written by 2k+ dev.
[22:02:11] <Mick99> this repo has like 7 branches
[22:02:13] *** elpargo has joined #jenkins
[22:02:14] <_Aeris_> kutzi > frequent good commits, it's just only few diff bytes
[22:02:35] <Mick99> okay i am seeing an intersting observation here
[22:02:55] *** protocol7 has quit IRC
[22:03:05] <Mick99> i added the --no-progress option in the command line as well and surprisingly it worked, when i analyzzed the wireshark output
[22:03:07] *** kenneth_reitz has joined #jenkins
[22:03:32] *** vivek_ has joined #jenkins
[22:03:40] <Mick99> more surprisingly it does not have --no-progress in that part of the code i posted earlier, it has this:
[22:03:52] <_Aeris_> Mick99 > if this is from old scm, there must have incorrect scm usages
[22:03:53] <_Aeris_> li
[22:04:04] <kohsuke> Are you saying that the progress option affects the HTTP requests?
[22:04:10] <_Aeris_> like multiples projects in trunk
[22:04:17] <_Aeris_> or scm-as-fs
[22:04:27] <Mick99> command prompt: 3843xxx883 jenkins: 00xxx725 multi_ack_detailed.side-band-64k-thin-pack.ofs-delta
[22:04:48] <Mick99> @kohsuke that's what i am observing, it wud be nice if someone can confirm it
[22:05:03] <_Aeris_> i try
[22:05:40] <Mick99> in command prompt both 'git clone -o origin repo workspace' and 'git clone --no-progress -o origin repo workspace' produce the same output
[22:06:28] <Mick99> whereas in jenkins, 'git clone -o origin repo workspace' produces this: 00xxx725 multi_ack_detailed.side-band-64k-thin-pack-no-progress.ofs-delta
[22:06:52] <Mick99> so why that no-progress gets passed in jenkins case and not for normal command line cases which work fine...
[22:07:20] *** andreasmandel1 has quit IRC
[22:07:24] <kohsuke> Must be different ~/.gitconfig
[22:07:48] <Mick99> its the same server with the same git path, repo, workspace etc
[22:07:57] <kutzi> _Aeris_ do you have a description somewhere what are *correct* scm usages ;) ?
[22:08:02] <kohsuke> ~/.gitconfig is a client setting
[22:08:02] <javabot> OK, kohsuke.
[22:08:04] <Mick99> even all the other calls in wireshark are exactly the same
[22:08:41] <Mick99> @kohsuke any command to check which .gitconfig is being pulled
[22:08:42] <kohsuke> And I think what's going on is that without progress report, the socket goes quiet for a long time, presumably while the server is busy creating the pack file
[22:08:59] <kohsuke> And Apache gets impatient and decides to shut down the socket
[22:09:19] <kohsuke> (I'm assuming that "git clone" sits there for a while, even for a failing case, before it chokes)
[22:09:58] <kohsuke> On Unix .gitconfig is in your home directory, but I don't know where it is in your case. If it's cygwin version of git, it must be looking at your cygwin home directory
[22:10:00] <Mick99> @kohsuke what you say makes total sense to me and i see its waits for a long time before choking so probably it times out...any workarounds?
[22:10:08] <kohsuke> But if it's a custom Windows build, those things tend to be modified.
[22:10:31] <kohsuke> A different transport would be ideal, if that's an option
[22:10:35] *** vivek_ has quit IRC
[22:10:57] <_Aeris_> Mick99 > where do you see those headers?
[22:11:03] <kohsuke> Failing that, looking for .gitconfig and tweaking it is still a reasonable option, I think.
[22:11:05] <_Aeris_> i haven't ><
[22:11:22] <Mick99> @kohsuke yes, i will try the git@ssh protocol next but usually for build accounts read account over http:// shud be sufficient and that's what we are trying to achieve
[22:11:45] <kohsuke> The other option is to modify the git plugin to add --progress
[22:12:05] <kohsuke> Mick99: are you prepared to compile a plugin by yourself :-) ?
[22:12:13] <Mick99> @_Aries_: Do you see content-length?
[22:12:38] <Mick99> @kohsuke yes for sure
[22:12:56] <_Aeris_> no content length?
[22:13:32] <kohsuke> Mick99: I should have a separate Wiki page for just checking out and building existing plugin, but for the time being http://wiki.jenkins-ci.org/display/JENKINS/Plugin+tutorial should help
[22:13:36] <Mick99> do you see the header at all - Uer-Agent, host, accept-encoding?
[22:13:36] <kohsuke> essentially it's just "mvn package"
[22:13:50] <_Aeris_> GET /aeris/esp.git/info/refs?service=git-upload-pack HTTP/1.1
[22:13:58] <Mick99> @kohsuke but which plugin wud u like me to build?
[22:14:11] <_Aeris_> Content-Type: application/x-git-upload-pack-advertisement
[22:14:20] <kohsuke> git-plugin
[22:14:23] <_Aeris_> POST /aeris/esp.git/git-upload-pack HTTP/1.1
[22:14:32] <_Aeris_> Content-Type: application/x-git-upload-pack-result
[22:14:33] <kohsuke> https://github.com/jenkinsci/git-plugin
[22:14:47] <Mick99> @kohsuke okay I will try to compile the git-plugin but did you made any fix or change?
[22:14:50] <kohsuke> and if you do "man git-clone" you see why it works for your shell.
[22:14:58] <_Aeris_> Mick99 > in which packet?
[22:15:31] <kohsuke> Under the --progress it says http://pastebin.com/QF52jTt4
[22:15:41] <Mick99> _Aeris_ under git-upload-pack HTTP/1.1
[22:15:52] <_Aeris_> i have one get, a response, a post and the response
[22:16:39] <kohsuke> Mick99: in GitAPI.java you see the clone method, which is where the clone is executed
[22:16:41] <_Aeris_> 0067want 786f3ef01285cc4209007602a1d1fa8514c4fa38 multi_ack_detailed side-band-64k thin-pack ofs-delta
[22:16:42] <_Aeris_> 00000009done
[22:16:50] <kohsuke> you add "args.add("--progress") there
[22:16:59] <_Aeris_> this is without progress nor no-progress
[22:17:20] <Mick99> alright, will add the --progress, try to recompile it and update you folks
[22:17:52] <_Aeris_> 0067want 786f3ef01285cc4209007602a1d1fa8514c4fa38 multi_ack_detailed side-band-64k thin-pack ofs-delta
[22:17:52] <_Aeris_> 00000009done
[22:18:00] <_Aeris_> with progress
[22:18:11] <_Aeris_> no difference?
[22:18:36] <kohsuke> Mick99: thanks for your patience, and I appreciate your trying things
[22:18:57] <_Aeris_> 0073want 786f3ef01285cc4209007602a1d1fa8514c4fa38 multi_ack_detailed side-band-64k thin-pack no-progress ofs-delta
[22:18:57] <_Aeris_> 00000009done
[22:19:08] <Mick99> @kohsuke no problems kohsuke, infact i wud like to thank you guys for helping me out
[22:19:09] <_Aeris_> with -q option
[22:19:19] <_Aeris_> there is no-progress here
[22:19:44] <kohsuke> Mick99: when this is all fixed and done, please blog/tweet about good folks in the Jenkins community :-) and help us spread the words
[22:20:03] <Mick99> @kohsuke the only thing I wud like to tell you is that Jenkins is a wonderful wonderful product and even in our corporation which is BIG(5K+ dev), we are moving from commercial products to Jenkins :)
[22:20:30] <_Aeris_> opensource is the future =)
[22:20:35] <kohsuke> Amen
[22:21:15] <Mick99> @kohsuke Hopefully will see you  guys pretty soon in person, amen
[22:21:28] <kohsuke> Where are you based?
[22:21:40] <Mick99> I am in toronto, canada
[22:21:53] <kohsuke> IBM?
[22:22:02] <_Aeris_> toronto?
[22:22:17] <Mick99> lol...nope, mobile related, i dont want to name .. lol
[22:22:30] <_Aeris_> bad remember?
[22:22:52] <Mick99> will meet u guys and tell in person and thank u
[22:24:27] <Mick99> @_Aeris_ did u managed to find the header?
[22:24:41] <_Aeris_> yes yes
[22:25:04] <_Aeris_> with -q option, there is one no-progress added
[22:26:58] *** vivek_ has joined #jenkins
[22:27:35] <kohsuke> Mick99: filed http://issues.jenkins-ci.org/browse/JENKINS-9168 for this
[22:27:36] <jenkins-admin> JENKINS-9168:"git clone" should add --progress (Open) http://jenkins-ci.org/issue/9168
[22:29:46] <Mick99> @kohsuke alright let's hope we can fix this asap...
[22:30:51] <kohsuke> Mick99: I'm counting on you to verify this hypothesis with your modified Git plugin
[22:30:53] <kohsuke> :-)
[22:31:26] <Mick99> @kohsuke i will try my best to compile my first git plugin, peace !!!
[22:32:28] <_Aeris_> kohsuke > perhaps you have a new problem with --progress
[22:32:40] 
[22:32:58] <kohsuke> I think I covered that in the ticket
[22:32:59] <_Aeris_> because git send \r periodically
[22:33:08] <_Aeris_> ah
[22:33:14] <_Aeris_> i look
[22:33:21] <Mick99> tortoise git usually puts both '--progress -v'
[22:39:59] *** Mick99 has quit IRC
[22:41:39] *** RSchulzM1 has quit IRC
[22:44:31] *** RSchulzM1 has joined #jenkins
[22:46:43] *** vivek_ has quit IRC
[23:08:26] *** cristhiank has joined #jenkins
[23:08:32] *** kutzi has quit IRC
[23:10:10] *** cristhiank_ has quit IRC
[23:10:28] *** cristhiank has quit IRC
[23:17:01] *** wilmoore has quit IRC
[23:17:45] *** Lewisham has joined #jenkins
[23:17:46] *** ChanServ sets mode: +v Lewisham
[23:20:18] <resmo_> hi
[23:20:32] *** resmo_ is now known as resmo
[23:52:21] *** Mick99 has joined #jenkins
[23:52:44] <Mick99> @kohsuke when i try to build the git-plugin, it fails with a dependancy error, see the full trace here - http://pastebin.com/Mzmqvbvw
[23:52:57] <Mick99> @kohsuke any help?
[23:55:13] <mwalling_> is that continuous?
[23:55:22] <mwalling_> m.g.o is giving a 503, it might go away
[23:55:30] <mwalling_> (maven.glassfish.org)
[23:58:44] <Mick99> @mwalling is that for me?





top