how can I increase session timeout when using jenkins with winston?

[ohad shai]

I am using jenkins with java -jar 
I want to increase session timeout for users login. how can I configure 
that?
Thanks,
Ohad.

Re: Can Jenkins host tar/zip files for the automatic installer?

[Jason Swager]

You can place arbitrary files in Jenkins userContent subdirectory, which 
exposes them as retrievable via URL, via wget or curl.  Or you can use the 
Copy to Slave plugin and pull the files directly from Jenkins to a 
workspace at the start the job. 

A bit more odd, but you can have a job that holds your files as part of 
it's artifacts.  Then use the Copy Artifact plugin to pull the files down 
to job workspaces.

Both solutions are sort of a self-contained within Jenkins, and better than 
having another server or service running on the network.

Jason

On Saturday, December 15, 2012 9:16:49 PM UTC-8, Jeff Vincent wrote:
>
> Thanks...that's what I ended up doing since I already have a Maven repo 
> available.  It just feels like it would be more "clean" for Jenkins to be 
> able to manage/serve all the files needed to do slave configuration or tool 
> setup without relying on an external service.
>
>
> On Sat, Dec 15, 2012 at 9:26 PM, Chris Marks 
> > wrote:
>
>> I'm not sure how to do this in Jenkins, but this seems like something 
>> that is more suited to a private binary or Maven repository such as 
>> Artifactory.  Although Maven repos have a slant toward jar files, there's 
>> no additional work to publish zip or tar files.  I once experimented with 
>> NMaven to store and retrieve .NET dlls in an Artifactory instance with no 
>> problems. 
>>
>> Thanks,
>> topher
>>
>>
>> On Sat, Dec 15, 2012 at 8:45 PM, Jeff > >wrote:
>>
>>> I'm playing with Jenkins slaves and want to create a custom zip/tar file 
>>> with configuration specific to our internal network that can be used for 
>>> the automatic installers (such as for Maven or GIT).
>>>
>>> Seems logical to have Jenkins host these files.  Is there a way to 
>>> upload or manually archive them in a way that would expose them as a url 
>>> that the automatic installers could use?
>>>
>>> -- 
>>> Jeff Vincent
>>> preda...@gmail.com 
>>> See my LinkedIn profile at:
>>> http://www.linkedin.com/in/rjeffreyvincent
>>> I ♥ DropBox  !!  
>>>
>>>  
>>
>
>
> -- 
> Jeff Vincent
> preda...@gmail.com 
> See my LinkedIn profile at:
> http://www.linkedin.com/in/rjeffreyvincent
> I ♥ DropBox  !!  
>
> 

Re: Can Jenkins host tar/zip files for the automatic installer?

[Jeff]

Thanks...that's what I ended up doing since I already have a Maven repo
available.  It just feels like it would be more "clean" for Jenkins to be
able to manage/serve all the files needed to do slave configuration or tool
setup without relying on an external service.


On Sat, Dec 15, 2012 at 9:26 PM, Chris Marks  wrote:

> I'm not sure how to do this in Jenkins, but this seems like something that
> is more suited to a private binary or Maven repository such as Artifactory.
>  Although Maven repos have a slant toward jar files, there's no additional
> work to publish zip or tar files.  I once experimented with NMaven to store
> and retrieve .NET dlls in an Artifactory instance with no problems.
>
> Thanks,
> topher
>
>
> On Sat, Dec 15, 2012 at 8:45 PM, Jeff  wrote:
>
>> I'm playing with Jenkins slaves and want to create a custom zip/tar file
>> with configuration specific to our internal network that can be used for
>> the automatic installers (such as for Maven or GIT).
>>
>> Seems logical to have Jenkins host these files.  Is there a way to upload
>> or manually archive them in a way that would expose them as a url that the
>> automatic installers could use?
>>
>> --
>> Jeff Vincent
>> predato...@gmail.com
>> See my LinkedIn profile at:
>> http://www.linkedin.com/in/rjeffreyvincent
>> I ♥ DropBox  !!
>>
>>
>


-- 
Jeff Vincent
predato...@gmail.com
See my LinkedIn profile at:
http://www.linkedin.com/in/rjeffreyvincent
I ♥ DropBox  !!

Re: Can Jenkins host tar/zip files for the automatic installer?

[Chris Marks]

I'm not sure how to do this in Jenkins, but this seems like something that
is more suited to a private binary or Maven repository such as Artifactory.
 Although Maven repos have a slant toward jar files, there's no additional
work to publish zip or tar files.  I once experimented with NMaven to store
and retrieve .NET dlls in an Artifactory instance with no problems.

Thanks,
topher


On Sat, Dec 15, 2012 at 8:45 PM, Jeff  wrote:

> I'm playing with Jenkins slaves and want to create a custom zip/tar file
> with configuration specific to our internal network that can be used for
> the automatic installers (such as for Maven or GIT).
>
> Seems logical to have Jenkins host these files.  Is there a way to upload
> or manually archive them in a way that would expose them as a url that the
> automatic installers could use?
>
> --
> Jeff Vincent
> predato...@gmail.com
> See my LinkedIn profile at:
> http://www.linkedin.com/in/rjeffreyvincent
> I ♥ DropBox  !!
>
>

Can Jenkins host tar/zip files for the automatic installer?

[Jeff]

I'm playing with Jenkins slaves and want to create a custom zip/tar file
with configuration specific to our internal network that can be used for
the automatic installers (such as for Maven or GIT).

Seems logical to have Jenkins host these files.  Is there a way to upload
or manually archive them in a way that would expose them as a url that the
automatic installers could use?

-- 
Jeff Vincent
predato...@gmail.com
See my LinkedIn profile at:
http://www.linkedin.com/in/rjeffreyvincent
I ♥ DropBox  !!

Re: Mixing svn, git, and hg

[Brad Knowles]

On Dec 15, 2012, at 9:13 AM, JR Cary  wrote:

> I can easily script pulling those in at their current states, but
> but with my several build machines, what I would like is to pull
> in all repos at the same version/state.  So that would mean that
> that master gets the sub-hg-repo at some id, then all slave builds
> update to the same id.
> 
> Any general tools for doing this?

One method you can use to do this sort of thing is to pull in all the repos you 
need on the master, then archive the workspace to be used as an SCM by the 
slaves.  I was doing this successfully at a previous client.

I think the plugin for this is at 
.


Note that when you archive the workspace (typically into a .tar.gz file), that 
doesn't include the .git and other source SCM subdirectories, so if there is 
anything that the slaves would need to extract from the repos themselves, you 
should do that before archiving the workspace and store that data into files 
that will be archived, which the slaves can then just read directly from the 
archive.

E.g., if the slave job needed to do something like a "git describe" in order to 
get the exact correct version information for the code being built, that should 
be done on the master and stored into a filename like 
"${WORKSPACE}/${BUILD_ID}.git-describe" or somesuch.

--
Brad Knowles 
LinkedIn Profile: 

Re: Warnings-Plugin: How to access the path of current workspace?

[Markus Schneider]

Hi,

Actually this what I have done in the regex. 
As you can see below, the groovy output has removed the relative path section. 
However, there is no concatenation with the workspace path:
> C:\programme\Jenkins\test-ci\workspace


Can I do some debugging? Which class is appending the complete path?

Markus

Am 15.12.2012 um 13:22 schrieb Ulli Hafner :

> I see, that can't work. 
> 
> Where is the src folder located? 
> C:\programme\Jenkins\test-ci\workspace\src?
> 
> My plug-in concatenates the workspace path and the found path in the warning, 
> which results in your case to 
> C:\programme\Jenkins\test-ci\workspace\..\..\..\src\test.c
> A simple solution would be to strip off the relative path section in your 
> groovy parser so that the concatenation works.
> 
> Ulli
> 
> Am 15.12.2012 um 11:37 schrieb Markus Schneider :
> 
>> Hi Ulli,
>> 
>> 
>> thanks for your help. Here is some more information:
>> 
>> Jenkins: V1.493
>> Warnings-Plugin: V4.18
>> Static Analysis Utilities: V1.48
>> OS: Windows XP
>> 
>> 
>> Workspace Path: C:\programme\Jenkins\test-ci\workspace
>> Example Warning:   "..\..\..\src\test.c", line 199: warning #550-D: variable 
>> "test" was set but never used
>> 
>> Parsed result  in parser configuration page is:
>> file name: src\test.c
>> line number: 199
>> category: #550-D
>> 
>> Project configuration uses "Scan workspace files"  with pattern **/*.log 
>> 
>> 
>> From warnings.xml:
>> 
>> src/test.c
>> src
>> 
>> 
>> -> path is not expanded in xml
>> 
>> 
>> Thanks,
>> Markus 
>> 
>> 
>> Am 14.12.2012 um 09:10 schrieb Ulli Hafner :
>> 
>>> Hmm, I thought that the files should contain at least the exception string.
>>> 
>>> Can you please provide some more information?
>>> What is your workspace path? Can you provide an example of a warning from 
>>> the build console log? What is the corresponding warning result in 
>>> warnings-[yourparsername].xml in the build folder? Is the path expanded 
>>> there? 
>>> 
>>> Thanks, Ulli
>>>  
>>> Am 13.12.2012 um 20:22 schrieb Markus Schneider :
>>> 
 Hello Ulli,
 
 Yes the relative path  does not work for me. The tmp files are generated, 
 but are empty. 
 
 Do I need a special configuration?
 
 Markus
 
 
 Am 13.12.2012 um 16:02 schrieb Ulli Hafner :
 
> Actually, a relative path (starting from the workspace root) should be 
> resolved automatically. Does this not work in your case?
> 
> Ulli
> 
> Am 12.12.2012 um 23:58 schrieb schneim :
> 
>> Hello,
>> 
>> 
>> I have created a custom warning parser. This works quite well. However, 
>> I have trouble to display the content of the source files.
>> 
>> I found out the path in the warning is only relative to the workspace 
>> path, e.g.  $WORKSPACE/src/file.c 
>> 
>> But for displaying the source file, the plugin requires the full path.
>> 
>> The question is, how to find the workspace path to concatenate it with 
>> the file path inside the groovy script.
>> 
>> import hudson.plugins.warnings.parser.Warning
>> 
>> String workspace = getWorkspacePath()
>> String fileName = matcher.group(1)
>> String fullPath = workspace+fileName
>> String lineNumber = matcher.group(2)
>> String category = matcher.group(3)
>> String message = matcher.group(4)
>> 
>> return new Warning(fullPath, Integer.parseInt(lineNumber), "Dynamic 
>> Parser", category, message);
>> 
>> 
>> Any way to find out the value for the workspace or some other solution 
>> available?
>> 
>> Thanks
>> 
>> --
>> Markus Schneider
>> markus.schnei...@jemm.de
> 

Subversion credentials ignored: "No credential to try"

[Mitch Gitman]

I'm running Jenkins in Tomcat 7 on an Ubuntu host.

When I go to enter a Subversion repository URL for a job, I get the
expected error message (specific locations replaced by ellipses):
 Unable to access https://... : svn: OPTIONS /… failed (show details)
(Maybe you need to enter credential?)

So I enter my credentials and they're successfully validated.

But now when I go back to the Subversion repository configuration for the
job, I keep getting the same error message. It's like the otherwise
accepted credentials never took hold.

Here's the subversion.credentials file that gets created for the job:


  

  ; wandisco
  
…
…
  

  


Note the use of the URL encoding and the "wandisco". I see similar content
getting persisted to a file hudson.scm.SubversionSCM.xml at the Jenkins
root.

Here's the associated stack trace:
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: No credential to
try. Authentication failed
 at
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:37)
at
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:32)
 at
org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getFirstAuthentication(DefaultSVNAuthenticationManager.java:219)
at
hudson.scm.FilterSVNAuthenticationManager.getFirstAuthentication(FilterSVNAuthenticationManager.java:35)
 at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:563)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:285)
 ... 63 more
Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: No credential to
try. Authentication failed
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:200)
 at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:146)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:89)

I installed a standalone svn client on this host, and that client was able
to check out source from the same repository, no problem. The configuration
in Jenkins home is being saved under the tomcat7 user.

I've also run Jenkins on Tomcat 7 on my Windows desktop, and that install
is able to hit the Subversion repository just fine configured the same way.
However, a per-job subversion.credentials file wasn't created on my
desktop, and the hudson.scm.SubversionSCM.xml doesn't contain any
credentials, which leads me to wonder how the Windows install is picking up
Subversion credentials that the Ubuntu isn't.

I'm using an older version of the Subversion Plugin, 1.34 instead of 1.43,
because of the "bad_record_mac" problem which one can find mentioned on
this list.

Happy to offer a reward for a solution. Will update this thread if I find
one myself. I bet this is nothing more than a Unix users thing.

Mixing svn, git, and hg

[JR Cary]

Are there any general approaches to mixing svn, git, and hg repos?

I have an uber project that is in an svn repo that pulls in almost
all of what it needs by svn externals.

Of course, as life would have it, I need to pull in one hg repo
and one git repo.

I can easily script pulling those in at their current states, but
but with my several build machines, what I would like is to pull
in all repos at the same version/state.  So that would mean that
that master gets the sub-hg-repo at some id, then all slave builds
update to the same id.

Any general tools for doing this?

ThxJohn Cary

Re: Maven version and upgrade - quick question

[domi]

hmm, I don't know of an option (Bundled) in jenkins - I think this is available 
in Hudson…
7Domi


On 14.12.2012, at 20:57, Z W  wrote:

> Hi All
> 
> Under Build section of a job,  Invoke Maven 3 - Maven 3, there is drop
> down value named (Bundled).
> How can we find out what version of Maven Jenkins is using ?
> When we want to use a newer Maven, how do we config under Manage
> Jenkins such that the slaves would pick up the newer
> Maven version ?
> 
> Thanks

Re: Warnings-Plugin: How to access the path of current workspace?

[Ulli Hafner]

I see, that can't work. 

Where is the src folder located? 
C:\programme\Jenkins\test-ci\workspace\src?

My plug-in concatenates the workspace path and the found path in the warning, 
which results in your case to 
C:\programme\Jenkins\test-ci\workspace\..\..\..\src\test.c
A simple solution would be to strip off the relative path section in your 
groovy parser so that the concatenation works.

Ulli

Am 15.12.2012 um 11:37 schrieb Markus Schneider :

> Hi Ulli,
> 
> 
> thanks for your help. Here is some more information:
> 
> Jenkins: V1.493
> Warnings-Plugin: V4.18
> Static Analysis Utilities: V1.48
> OS: Windows XP
> 
> 
> Workspace Path: C:\programme\Jenkins\test-ci\workspace
> Example Warning:   "..\..\..\src\test.c", line 199: warning #550-D: variable 
> "test" was set but never used
> 
> Parsed result  in parser configuration page is:
> file name: src\test.c
> line number: 199
> category: #550-D
> 
> Project configuration uses "Scan workspace files"  with pattern **/*.log 
> 
> 
> From warnings.xml:
> 
> src/test.c
> src
> 
> 
> -> path is not expanded in xml
> 
> 
> Thanks,
> Markus 
> 
> 
> Am 14.12.2012 um 09:10 schrieb Ulli Hafner :
> 
>> Hmm, I thought that the files should contain at least the exception string.
>> 
>> Can you please provide some more information?
>> What is your workspace path? Can you provide an example of a warning from 
>> the build console log? What is the corresponding warning result in 
>> warnings-[yourparsername].xml in the build folder? Is the path expanded 
>> there? 
>> 
>> Thanks, Ulli
>>  
>> Am 13.12.2012 um 20:22 schrieb Markus Schneider :
>> 
>>> Hello Ulli,
>>> 
>>> Yes the relative path  does not work for me. The tmp files are generated, 
>>> but are empty. 
>>> 
>>> Do I need a special configuration?
>>> 
>>> Markus
>>> 
>>> 
>>> Am 13.12.2012 um 16:02 schrieb Ulli Hafner :
>>> 
 Actually, a relative path (starting from the workspace root) should be 
 resolved automatically. Does this not work in your case?
 
 Ulli
 
 Am 12.12.2012 um 23:58 schrieb schneim :
 
> Hello,
> 
> 
> I have created a custom warning parser. This works quite well. However, I 
> have trouble to display the content of the source files.
> 
> I found out the path in the warning is only relative to the workspace 
> path, e.g.  $WORKSPACE/src/file.c 
> 
> But for displaying the source file, the plugin requires the full path.
> 
> The question is, how to find the workspace path to concatenate it with 
> the file path inside the groovy script.
> 
> import hudson.plugins.warnings.parser.Warning
> 
> String workspace = getWorkspacePath()
> String fileName = matcher.group(1)
> String fullPath = workspace+fileName
> String lineNumber = matcher.group(2)
> String category = matcher.group(3)
> String message = matcher.group(4)
> 
> return new Warning(fullPath, Integer.parseInt(lineNumber), "Dynamic 
> Parser", category, message);
> 
> 
> Any way to find out the value for the workspace or some other solution 
> available?
> 
> Thanks
> 
 
>> 
> 
> --
> Markus Schneider
> markus.schnei...@jemm.de
> 
> 
> 
> 

Re: Warnings-Plugin: How to access the path of current workspace?

[Markus Schneider]

Hi Ulli,


thanks for your help. Here is some more information:

Jenkins: V1.493
Warnings-Plugin: V4.18
Static Analysis Utilities: V1.48
OS: Windows XP


Workspace Path: C:\programme\Jenkins\test-ci\workspace
Example Warning:   "..\..\..\src\test.c", line 199: warning #550-D: variable 
"test" was set but never used

Parsed result  in parser configuration page is:
file name: src\test.c
line number: 199
category: #550-D

Project configuration uses "Scan workspace files"  with pattern **/*.log 


From warnings.xml:

src/test.c
src


-> path is not expanded in xml


Thanks,
Markus 


Am 14.12.2012 um 09:10 schrieb Ulli Hafner :

> Hmm, I thought that the files should contain at least the exception string.
> 
> Can you please provide some more information?
> What is your workspace path? Can you provide an example of a warning from the 
> build console log? What is the corresponding warning result in 
> warnings-[yourparsername].xml in the build folder? Is the path expanded 
> there? 
> 
> Thanks, Ulli
>  
> Am 13.12.2012 um 20:22 schrieb Markus Schneider :
> 
>> Hello Ulli,
>> 
>> Yes the relative path  does not work for me. The tmp files are generated, 
>> but are empty. 
>> 
>> Do I need a special configuration?
>> 
>> Markus
>> 
>> 
>> Am 13.12.2012 um 16:02 schrieb Ulli Hafner :
>> 
>>> Actually, a relative path (starting from the workspace root) should be 
>>> resolved automatically. Does this not work in your case?
>>> 
>>> Ulli
>>> 
>>> Am 12.12.2012 um 23:58 schrieb schneim :
>>> 
 Hello,
 
 
 I have created a custom warning parser. This works quite well. However, I 
 have trouble to display the content of the source files.
 
 I found out the path in the warning is only relative to the workspace 
 path, e.g.  $WORKSPACE/src/file.c 
 
 But for displaying the source file, the plugin requires the full path.
 
 The question is, how to find the workspace path to concatenate it with the 
 file path inside the groovy script.
 
 import hudson.plugins.warnings.parser.Warning
 
 String workspace = getWorkspacePath()
 String fileName = matcher.group(1)
 String fullPath = workspace+fileName
 String lineNumber = matcher.group(2)
 String category = matcher.group(3)
 String message = matcher.group(4)
 
 return new Warning(fullPath, Integer.parseInt(lineNumber), "Dynamic 
 Parser", category, message);
 
 
 Any way to find out the value for the workspace or some other solution 
 available?
 
 Thanks
 
>>> 
> 

--
Markus Schneider
markus.schnei...@jemm.de