Re: unable to access Jenkins in Firefox and Chrome after latest browser updates because of "weak ephemeral Diffie-Hellman public key"

[Brent Atkinson]

https://productforums.google.com/forum/#!topic/chrome/o3vZD-Mg2Ic

On Tue, Oct 27, 2015 at 1:31 PM, Roger Moore 
wrote:

> Has anyone else seen a problem accessing Jenkins after Chrome was updated
> to v45? Chrome reports:
>
> "This error can occur when connecting to a secure (HTTPS) server. It means
> that the server is trying to set up a secure connection but, due to a
> disastrous misconfiguration, the connection wouldn't be secure at all!
>
> In this case the server needs to be fixed. Google Chrome won't use
> insecure connections in order to protect your privacy."
>
> A similar error occurs in Firefox v39.0, which reports:
>
> "An error occurred during a connection to 'servername:portnumber'. SSL
> received a weak ephemeral Diffie-Hellman key in Server Key Exchange
> handshake message. (Error code: ssl_error_weak_server_ephemeral_dh_key)."
>
> I can connect using IE and Safari though.
>
> The Jenkins logs do not provide messages at the time when the attempt to
> connect is made.
>
> I tried looking at the Jenkins configuration and using Google searches,
> but could not find where to change the setting in Jenkins to force Jenkins
> to use the stronger key.
>
> Any suggestions would be appreciated.
>
>
>
> Roger Moore
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/SN1PR08MB198183FA4F85C5148C4BB6220%40SN1PR08MB1981.namprd08.prod.outlook.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CALyHw0HLs%2BOi8_58-W6gAwfSK0k-%3DOgRi_M4bSngm4tOs319EA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins with microcontrollers

[Brent Atkinson]

Hi Matheus,

Dick beat me to it.

It's unclear from the information you have offered whether Jenkins itself
would speed up your particular process. However, Jenkins can automatically
detect changes in some source and run the manual process you are currently
using automatically. The catch is that the commands need to be executable
from a Jenkins supported platform, or run remotely from such a platform.
This could be over most any transport. Presumably, you already have this
working from the systems you are developing on - serial lines, etc.

Brent

On Tue, Oct 13, 2015 at 12:59 PM, Matheus Frata  wrote:

> Hi,
>
> Do you guys know if i can use Jenkins with microcontrollers?
>
> Test specific function, expecting a know output;
> Test a routine and so on...
>
> Here in the lab, a group will launch a cubeSAT and i need to know if
> Jenkins will help the software team to speed up the tests.
>
> Best regards,
> Matheus Frata.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/1160788d-b61f-43cc-b9ef-54ba19673930%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CALyHw0Hb%3DCcErjq3qaxBwPWroL8%2BBGQbD_Rf%3DwF1nT_inZx2Rw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins, Web application server and Nexus

[Brent Atkinson]

He means the Apache Tomcat manager app. It provides the means to
programmatically deploy to Tomcat. JBoss has similar  functionality exposed
through its management services, though you may have to enable/secure it.
This assumes your server lives longer than a deployment, which is not how
everyone does it.
On Aug 20, 2015 8:05 PM, "Martin"  wrote:

> Hi, Jeff:
>
> What do you mean by the "manager application" in the description of
> "manager application to be installed and configured"? Is it Nexus? Thanks.
>
> On Thursday, August 20, 2015 at 7:43:34 PM UTC-4, Jeff Vincent wrote:
>>
>> I don't know anything about JBoss, but Apache (Tomcat) doesn't 'grab'
>> anything.  You have to push the build to the server either using the tomcat
>> manager API or use some other mechanism (SCP, wget, etc.) to otherwise grab
>> the WAR file and get it onto the server.
>>
>> Jenkins has the 'deploy war/ear to a container' plugin to facilitate
>> this, but it requires (in the case of tomcat) the manager application to be
>> installed and configured.  If your production environment is like ours,
>> they will not install the manager application so it is either
>> copied/configured manually or you can script it via a provisioning tool
>> (SaltStack, Chef, Ansible, Puppet, etc.) and there are numerous ways to do
>> it through any of those tools.
>>
>>
>>
>> On Thu, Aug 20, 2015 at 5:12 PM, Martin  wrote:
>>
>>> If I use Nexus OSS as a repository manager, the normal for code goes to
>>> production system is something like below:
>>>
>>> 1) Jenkins grabs code from Perforce or GIT server
>>> 2) Jenkins retrieves dependencies from Nexus
>>> 3) Jenkins test and build the project
>>> 4) The build is deployed to Nexus from Jenkins
>>> 5) Web application server, i.e. JBoss Application Server or Apache
>>> Server grabs code from Nexus, for production service.
>>>
>>> In this flow, the build in Jenkins doesn't directly go or deploy to Web
>>> server, but first parked at Nexus, and goes to Web server.
>>>
>>> Is this understanding right? I would appreciation an explanation for
>>> this cycle.
>>>
>>> --
>>> 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-use...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-users/5ff2816c-3d23-42f4-bfde-103e7f8626fb%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Jeff Vincent
>> See my LinkedIn profile at:
>> http://www.linkedin.com/in/rjeffreyvincent
>>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/e1a17020-6646-49db-b8d8-b95d30c11886%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CALyHw0EKvu%3DdnAw8PLHvUtcHQCPxd3bYVLYBtMKXS9Sk4xVd8g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins, Web application server and Nexus

[Brent Atkinson]

Hi Martin,

The way you describe is similar to approaches I have seen before. However,
as Jeff said, how you would do this is a matter of what you are looking to
achieve and how you have setup your processes and environments.

Given how you describe [5] I assume you may be manually configuring from
some sort of deployment script? Other organizations may use their build
pipeline to automatically deploy built and tested artifacts to one or more
environments (like qa, preview, production).

They key idea to the type of configuration you are talking about is
ensuring that you can't put code into production without it being checked
in, built off a developer's machine, unit and integration tests pass, and
whatever else your organization treats as pre-release requirements.

HTH,

Brent





On Thu, Aug 20, 2015 at 7:12 PM, Martin  wrote:

> If I use Nexus OSS as a repository manager, the normal for code goes to
> production system is something like below:
>
> 1) Jenkins grabs code from Perforce or GIT server
> 2) Jenkins retrieves dependencies from Nexus
> 3) Jenkins test and build the project
> 4) The build is deployed to Nexus from Jenkins
> 5) Web application server, i.e. JBoss Application Server or Apache Server
> grabs code from Nexus, for production service.
>
> In this flow, the build in Jenkins doesn't directly go or deploy to Web
> server, but first parked at Nexus, and goes to Web server.
>
> Is this understanding right? I would appreciation an explanation for this
> cycle.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/5ff2816c-3d23-42f4-bfde-103e7f8626fb%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CALyHw0FdqN3w0%2BtQVQ-SOEeQS2CiRg%3DUHQrV%2BThCb_5HkPcThA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Artifactory issues

[Brent Atkinson]

Tommy,

If you are using bridged networking (definitely not NAT) and are on a
network where you can safely assign the VM a different static IP, you need
to start by configuring the VM an IP that is not in an IPv4 private address
space. Once you have done this, you should attempt to access Artifactory
from outside your local network (by browser, etc) to ensure that no routing
rules or packet filtering will prevent access from the EC2 instance. If
that works, you should be good to go.

Hope that helps,
Brent

On Thu, Apr 16, 2015 at 7:04 PM, Tommy Cregan 
wrote:

>
>
> On Thursday, April 16, 2015 at 11:14:33 PM UTC+1, Tommy Cregan wrote:
>>
>> Hi all,
>>
>> I'm having a bit of trouble with the *Artifactory Server* details in
>> Jenkins. I have *Artifactory* running in *Virtual Box* localhost:8081 on
>> *Ubuntu* and I have configured
>> the *Ubuntu* instance of this *VM* with a *Static IP* and bridged
>> networking. I have *Jenkins* running on an Ubuntu instance on *Amazon
>> AWS* and I'm trying to configure
>> the Artifactory Servers IP address in Jenkins configuration page for
>> *Maven* deployment. The IP address keeps failing in the test. What am I
>> doing wrong? Also,
>> are the Default Deployer Credentials supposed to be my *Jenkins*
>> credentials or the Artifactory user and password I have also configured?
>>
>I am entering the VM's static IP in the Artifactory URL like
> http://192.168.xx.xx:8081/artifactory. I understand this IP is insulated
> from external
>access so what are the alternatives?  Any help is much
>appreciated.
>
>>
>>
>> Tommy
>>
>  --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/44408722-bb44-462f-a9e5-74dae7432cd3%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CALyHw0GS883sTFWzSSKTka9G0X9tj%3DvgtPVQPAQOeguMK-fMPg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sandboxed Maven builds on Jenkins

[Brent Atkinson]

Hi Jozo,

Yes, you should be able to do something like that. However, your feeling
isn't quite right: it is fairly common for people to provision hosts and
tear-down them down part of the build. One reason this is advantageous is
that your "cleanup" can fail and then your build environment is corrupt and
builds start failing (or worse, don't fail but yield bad output silently).

Just as an example, here's a group doing it with Vagrant and VMs:
http://pivotallabs.com/spinning-useful-vms-quickly-vagrant-puppet-puppet-forge/

Brent

On Thu, Apr 16, 2015 at 5:51 PM, Jozef Vilcek  wrote:

> Actually, Jenkins build environment I use does distributed builds (I do
> not manage this). I have a feeling that agent setup is rather static.
> Projects I need to build have native dependencies, which can change a lot.
> There are many projects, they share build cluster and there dependencies
> can be often in conflict.
>
> Can I do something like:
> * setup an agent with desired OS and basic setup (libraries)
> * project X build gets triggered
> * project is assigned to the agent
> * pre-build step is executed, which takes from workspace file list of
> libraries specific to project X and install them
> * maven build is executed -> everything is green
> * cleanup
> * ...
> * project Y build gets triggered
> * by chance, it is assigned to the same agent
> * there is no trace of any library installed by project X
> * pre-build step installs libraries specific to project Y
> * ... etc
>
> On Thu, Apr 16, 2015 at 11:33 PM, Brent Atkinson  > wrote:
>
>> Hi Jozo,
>>
>> Yes, I was using the less incendiary term for the distributed build
>> agents (or slaves), so you found the right docs.
>>
>> "Container" was referring to something like, but not necessarily Docker
>> containers.
>>
>> When you use agents, you are typically do it to:
>>
>>   * unload the load from the build master
>>   * need to build on different operating system or architecture from the
>> master
>>   * need to build in an isolated or preconfigured environment different
>> from the master
>>
>> That last one would seem to align with your question, unless there's a
>> reason you didn't want to use distributed builds.
>>
>> Hope that helps,
>>
>> Brent
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Jenkins Users" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/jenkinsci-users/ZISjWJ48VNY/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> jenkinsci-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-users/CALyHw0GGSvDR29di81zROJn3A6d5G7vtK4mF7gZ7CWEwS%3D5GFw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-users/CALyHw0GGSvDR29di81zROJn3A6d5G7vtK4mF7gZ7CWEwS%3D5GFw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/CAOUjMkwvAoOYTEt8s9d7rKu_GHMurugSHWsQV%3DfFtmZmfbra%3Dw%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-users/CAOUjMkwvAoOYTEt8s9d7rKu_GHMurugSHWsQV%3DfFtmZmfbra%3Dw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CALyHw0EzDORvkwntDYSMnK92iZ_nTocRU0Qfwt1cMmVfW-cVwA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sandboxed Maven builds on Jenkins

[Brent Atkinson]

Hi Jozo,

Yes, I was using the less incendiary term for the distributed build agents
(or slaves), so you found the right docs.

"Container" was referring to something like, but not necessarily Docker
containers.

When you use agents, you are typically do it to:

  * unload the load from the build master
  * need to build on different operating system or architecture from the
master
  * need to build in an isolated or preconfigured environment different
from the master

That last one would seem to align with your question, unless there's a
reason you didn't want to use distributed builds.

Hope that helps,

Brent

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CALyHw0GGSvDR29di81zROJn3A6d5G7vtK4mF7gZ7CWEwS%3D5GFw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sandboxed Maven builds on Jenkins

[Brent Atkinson]

Hi,

I may be missing something, but is there a reason you aren't just
provisioning VMs or containers and using normal maven builds using agents?

Brent

On Thu, Apr 16, 2015 at 4:56 PM, Jozo Vilcek  wrote:

> I have asked this question on stack overflow:
>
> http://stackoverflow.com/questions/2995/sandboxed-maven-builds-on-jenkins/
>
> Any help is much appreciated!
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/b0f048f9-90a6-4237-84d0-caae29fec7a7%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CALyHw0GGpxgA_aoH2zYPbkpWcJkLGqTdhbKP%3D45VKCbkFmQQMQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Hiring-Oracle Pl/SQL with Unix Shell Scripting@Boston MA [Please send resumes to r...@technotalent.com]

[Brent Atkinson]

>
> Note: This email is not intended to be a solicitation. It is targeted to
> recruiting and consulting professionals. If you have received this in
> error, please accept our apologies and to be removed from our mailing list
> reply with "UNSUBSCRIBE" in the subject heading and your email address in
> the body.


I have received this in error. UNSUBSCRIBE ;P

On Wed, Feb 25, 2015 at 2:28 PM, Rene Mickey  wrote:

> Hi,
>
> Hope you are doing great...
>
>
> (*If you are not interested or not available Please refer this position)*
>
>
> [Please send resumes to r...@technotalent.com]
>
> *Position :*
>
> *Title :* *Oracle Pl/SQL with Unix Shell Scripting*
>
> *Location : **Boston MA *
>
> *Duration : 6Months +*
>
> *Type of position: C2C*
>
>
>
> *Job Description*
>
> · 5 - 7 years hands on development experience on the core skills
> and Business Related Skills elaborated below
>
> · In addition to the technical skills, the candidate should be
> organized, self-managed and have the ability to track deliverables in
> multiple projects concurrently.
>
> · Should have extensive design and coding experience of critical
> enterprise applications, preferably for big banks or financial institutions
>
> · Should be able to work in Agile model and some exposure to Agile
> will be preferable
>
> · Good working understanding of Securities Lending or some
> exposure to working in projects for financial institutions preferable.
>
> · Should be self driven with very good communication skills.
>
> · *Core skills*
>
> · Hands on experience in advanced database programming including
> building generic framework, Oracle queues, object collections.  Defensive
> coding skills to handle unexpected scenarios gracefully.
>
> · Experience in writing meta-data driven programming.
>
> · Experience in handling hierarchical data in a RDBMS data setting.
>
> · Experience in working in a controlled production/UAT
> environments.  Example – planning ahead of time to include diagnostics
> during development because debug code cannot be deployed in production/UAT
> at will.
>
> · Has experience with scripting language such as shell, perl in
> linux environment for quickly implementing a change.
>
> · Understanding of UNIX/Linux hardware concepts especially as it
> relates to storage and networked file systems and grid computing.
>
> · Design and develop data integration and mapping scripts to
> transfer data seamlessly from vendor product and internal source
> systems/custom applications; Example: integration of external provider data
> API to collect data and store in a normalized database, develop intelligent
> extraction process to consume data incrementally etc.
>
> · Develop/Configure and deploy complete systems on Development,
> User Acceptance Testing and Production environments; design and develop
> system monitoring scripts to optimize support functions and daily systems
> operation, DR test.
>
> · Co-ordinate with various teams in the bank for upstream and
> downstream feeds, infrastructure related activities etc.
>
> · Experience with large volume data handling and sql tuning for
> better performance in data warehouse environment.
>
> · Understanding of market data will be a huge plus.
>
> *Business Related Skills*
>
> · Exposure on pricing and simulation models of FX, option and
> fixed income products/instruments.
>
> · Understanding of credit and market risk measures involved.
>
> · Experience working in analytical risk platforms such as
> Algorithmics with large data volume such as few hundred thousand trades,
> scenarios etc.
>
> · Exposure on various Algorithmics components such as risk watch,
> scenario engine.
>
>
>
> *Skills*
>
> *Experience*
>
> *Mandatory/Optional*
>
> Oracle Pl/ SQL
>
> 5
>
> M
>
> UNIX Shell Scripting
>
> 3
>
> M
>
>
>
> *Please reply me with below details along with your resume..*
>
>
>
> Candidate Full Name (First Last):
>
> Core Expertise:
>
> Total Years of Exp:
>
> Current Location (City, State):
>
> Relocation Preference:
>
> Availability:
>
> SSN (last 4 Digits):
>
> Candidate Contact #:
>
> Candidate Email ID :
>
> Candidate Skype ID :
>
>
>
> Visa Status (H1B / EAD / GC / Citz /...):
>
> If H1B / EAD then Validity (Mon, Year)  :
>
> Candidate Date of Birth (Month, Year) :
>
> Education Course Name:
>
> University Name:
>
> City, State, Country:
>
> Year Completed:
>
>
>
> Project Reference 1:
>
>
>
> Project References 2:
>
>
>
>
> Regards,
> *Rene*
> TechnoTalent Software Solutions,707 Alexander Rd.208.
> Princeton, New Jersey 08540.
> *Email: **r...@technotalent.com* 
>
> *D: 732-444-3663 <732-444-3663>*
> URL: www.technotalent.com
>
> Note: This email is not intended to be a solicitation. It is targeted to
> recruiting and consulting professionals. If you have received this in
> error, please accept our apologies

Re: Trac Publisher plugin

[Brent Atkinson]

>
> Jenkins 1.529
> Trac Plugin 1.13
> Trac Publisher 1.3
>
> Trac 0.11.7-4
> trac-xmlrpc 1.0.6+svn6598-1


Could you also provide the configuration settings you are using?

127.0.0.1 - - [29/Aug/2013:18:10:49 -0400] "POST /trac HTTP/1.1" 500 829
> "-" "Apache XML RPC 3.1.3 (Jakarta Commons httpclient Transport)"
>


> [Thu Aug 29 18:10:49 2013] [error] [client 127.0.0.1] mod_wsgi
> (pid=11632): Exception occurred processing WSGI script
> '/home/user/webproject.trac/cgi-bin/trac.wsgi'.
> [Thu Aug 29 18:10:49 2013] [error] [client 127.0.0.1] RuntimeError:
> response has not been started


These are telling you that Trac is encountering an error and it is
returning an HTTP 500 error. This could be for a number of reasons, but
Trac does a terrible job of reporting the reason, and instead just returns
"RuntimeError: response has not been started". My advice would be to try
and use the xmlrpc interface with the use you setup for jenkins. If you can
verify it works manually, then it confirms this is a defect in the plugin.
Unfortunately, I can't use your setup so you will have to help to identify
any issue.

I'd also check the file permissions and xmlrpc setup and make sure that all
looks good. Just searching on google for "RuntimeError: response has not
been started" shows how many people get this error from Trac for a number
of reasons.

Brent


On Thu, Aug 29, 2013 at 6:32 PM, Daniel Ritchie wrote:

> I'll join Magnus on this being an unresolved issue for us. In my scenario,
> we're using Debian 6.0.7 apt versions of Jenkins and Trac.
>
> Jenkins 1.529
> Trac Plugin 1.13
> Trac Publisher 1.3
>
> Trac 0.11.7-4
> trac-xmlrpc 1.0.6+svn6598-1
>
> Basically, take today's Debian Squeeze (previous stable), install both
> locally, and let Jenkins install and upgrade its own plugins. That's what I
> did this week.
>
> The result is that Trac Publisher behaves exactly as Magnus has described.
> Console output of a build claims success on commenting to the ticket, but
> it's not true. This is what I see in Apache access.log:
>
> 127.0.0.1 - - [29/Aug/2013:18:10:49 -0400] "POST /trac HTTP/1.1" 500 829
>> "-" "Apache XML RPC 3.1.3 (Jakarta Commons httpclient Transport)"
>>
>
> And this is error.log:
>
> [Thu Aug 29 18:10:49 2013] [error] [client 127.0.0.1] mod_wsgi
>> (pid=11632): Exception occurred processing WSGI script
>> '/home/user/webproject.trac/cgi-bin/trac.wsgi'.
>> [Thu Aug 29 18:10:49 2013] [error] [client 127.0.0.1] RuntimeError:
>> response has not been started
>>
>
> Having configured Jenkins to use a brand-new Trac account, I can also see
> that this exception prevented Jenkins from having logged an access on Trac,
> because the user's "Last Login" is still null. Also note that this occurs
> with or without a user/password pair.
>
>
>
> On Monday, 15 April 2013 16:07:45 UTC-4, Brent Atkinson wrote:
>
>> Magnus,
>>
>> I was able to successfully using:
>>
>>   * Jenkins ver. 1.480.3 w/Trac Publisher Plugin 1.3
>>   * Trac 1.0.1 w/XmlRpcPlugin 1.1.2-r12546
>>
>> I configured the sample build by:
>>
>>   * Checking the 'Add link to Trac issues' checkbox
>>   * URL = 
>> http://example.com/trac/login/**rpc<http://example.com/trac/login/rpc>
>>   * User = user with permissions
>>   * Password = user's password
>>
>> I simply made a commit using:
>>
>> svn commit -m "#1: testing publisher plugin for trac 1.0.1"
>>
>> And when built, a message in the console output shows:
>>
>> Updating 1 Trac issue(s): 
>> server=http://example.com/**trac/login/rpc<http://example.com/trac/login/rpc>,
>>  user=xmlrpcuser
>> Updating successful issue 1 with sample #4
>>
>> Checking the ticket referenced, it was successfully updated (once I set
>> jenkin's 'Jenkins URL')
>>
>> So, the good news is, it should work. The bad news is, there isn't a
>> whole lot that can go wrong here. If you don't see the message in the
>> console output, it seems the plugin isn't running. If you can give more
>> details about what you have setup, it would help to venture a better guess.
>>
>> Brent
>>
>> On Mon, Apr 15, 2013 at 1:17 AM, Magnus Therning wrote:
>>
>>> On Sun, Apr 14, 2013 at 11:28:34AM -0400, Brent Atkinson wrote:
>>> > Magnus,
>>> >
>>> > Yes you are right about the logging. You should definitely be seeing an
>>> > attempt to update the tickets in the trailing line

Re: Trac Publisher plugin

[Brent Atkinson]

Magnus,

I was able to successfully using:

  * Jenkins ver. 1.480.3 w/Trac Publisher Plugin 1.3
  * Trac 1.0.1 w/XmlRpcPlugin 1.1.2-r12546

I configured the sample build by:

  * Checking the 'Add link to Trac issues' checkbox
  * URL = http://example.com/trac/login/rpc
  * User = user with permissions
  * Password = user's password

I simply made a commit using:

svn commit -m "#1: testing publisher plugin for trac 1.0.1"

And when built, a message in the console output shows:

Updating 1 Trac issue(s): server=http://example.com/trac/login/rpc ,
user=xmlrpcuser
Updating successful issue 1 with sample #4

Checking the ticket referenced, it was successfully updated (once I set
jenkin's 'Jenkins URL')

So, the good news is, it should work. The bad news is, there isn't a whole
lot that can go wrong here. If you don't see the message in the console
output, it seems the plugin isn't running. If you can give more details
about what you have setup, it would help to venture a better guess.

Brent

On Mon, Apr 15, 2013 at 1:17 AM, Magnus Therning wrote:

> On Sun, Apr 14, 2013 at 11:28:34AM -0400, Brent Atkinson wrote:
> > Magnus,
> >
> > Yes you are right about the logging. You should definitely be seeing an
> > attempt to update the tickets in the trailing lines of the build output.
> As
> > for the multi-project comment, the plugin was actually written based on
> the
> > xmlrpc interface of trac 0.11. However, you should at least see failures
> in
> > http logs or on the Jenkins side. What you are seeing sounds strange.
>
> Yes, that is what I was thinking too.  I had a quick look at the code
> of the plugin, while it's not chatty it's definitely not completely
> quiet either.
>
> I don't see anything related to Trac Publisher in
>
>  - webserver logs on the Trac side
>  - build logs of the Jenkins build jobs
>  - stdout on the Jenkins server (I still haven't turned Jenkins into a
>service so I see its output on the terminal where I started it)
>
> Is there some other place I should be looking for errors and warnings
> that could explain the behaviour?
>
> /M
>
> --
> Magnus Therning  OpenPGP: 0xAB4DFBA4
> email: mag...@therning.org   jabber: mag...@therning.org
> twitter: magthe   http://therning.org/magnus
>
> Most software today is very much like an Egyptian pyramid with
> millions of bricks piled on top of each other, with no structural
> integrity, but just done by brute force and thousands of slaves.
>  -- Alan Kay
>

-- 
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://groups.google.com/groups/opt_out.

Re: Trac Publisher plugin

[Brent Atkinson]

Magnus,

Yes you are right about the logging. You should definitely be seeing an
attempt to update the tickets in the trailing lines of the build output. As
for the multi-project comment, the plugin was actually written based on the
xmlrpc interface of trac 0.11. However, you should at least see failures in
http logs or on the Jenkins side. What you are seeing sounds strange.

Brent
On Apr 14, 2013 11:13 AM, "Magnus Therning"  wrote:

> On Sun, Apr 14, 2013 at 08:26:57AM -0400, Brent Atkinson wrote:
> > Magnus,
> >
> > If I remember correctly, the pattern is similar if not the same as
> > Trac's issue pattern. It is odd you don't see anything at all in the
> > build log, but since you mentioned you are using trac 1.0 and a
> > project, the xmlrpc interface may not be compatible. It was built on
> > older revs of trac that didnt support multiple projects.
>
> Wouldn't the plugin report the error to the build log (or somewhere
> else)?
> If it tries to use the URL I provided I ought to see something in the
> webserver's access log on tracsrv.local.  However, I really see
> *nothing*.  So it looks like the plugin never runs at all.
>
> > There is not a lot of information to go on here, but I have been
> > meaning to try the plugin in a trac 1.0 multi-project setup since it
> > may break assumptions this was built on. Feel free to take a peek at
> > the source yourself in the mean time. It is a quick read.
>
> I'm not sure what you mean by multi-project, but AFAIK nothing that
> would qualify as multi-project in my mind has entered Trac since 0.12.
> When I mentioned 'project' in the earlier post I think I was referring
> to a 'Jenkins project'.
>
> /M
>
> --
> Magnus Therning  OpenPGP: 0xAB4DFBA4
> email: mag...@therning.org   jabber: mag...@therning.org
> twitter: magthe   http://therning.org/magnus
>
>
> Perl is another example of filling a tiny, short-term need, and then
> being a real problem in the longer term.
>  -- Alan Kay
>

-- 
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://groups.google.com/groups/opt_out.

Re: Trac Publisher plugin

[Brent Atkinson]

Magnus,

If I remember correctly, the pattern is similar if not the same as Trac's
issue pattern. It is odd you don't see anything at all in the build log,
but since you mentioned you are using trac 1.0 and a project, the xmlrpc
interface may not be compatible. It was built on older revs of trac that
didnt support multiple projects.

There is not a lot of information to go on here, but I have been meaning to
try the plugin in a trac 1.0 multi-project setup since it may break
assumptions this was built on. Feel free to take a peek at the source
yourself in the mean time. It is a quick read.

Brent
On Apr 14, 2013 2:30 AM, "Magnus Therning"  wrote:

> On Sat, Apr 13, 2013 at 07:54:48PM +0200, Magnus Therning wrote:
> [...]
> > - Trac Publisher - 1.3
> >
> > Trac XMLRPC URL : http://tracsrv.local/trac/ProjectFoo/login/rpc
> > (also tried http://tracsrv.local/trac/ProjectFoo/login/xmlrpc,
> > with no luck)
> > Trac XMLRPC username : magnus (with correct username)
>
> Just for fun I changed the URL to the wrong one, one that doesn't
> require authentication.  I still see *nothing* in the build log on the
> Jenkins side.
>
> Something that hit me yesterday is that I don't *know* what Trac
> Publisher is looking for in the commit messages.  I just assumed it
> would work with the same strings as the Trac CommitTicketUpdater
> plugin does.  Is that assumption correct?
>
> /M
>
> --
> Magnus Therning  OpenPGP: 0xAB4DFBA4
> email: mag...@therning.org   jabber: mag...@therning.org
> twitter: magthe   http://therning.org/magnus
>
> I invented the term Object-Oriented, and I can tell you I did not have
> C++ in mind.
>  -- Alan Kay
>

-- 
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://groups.google.com/groups/opt_out.

Re: Track Publisher plugin

[Brent Atkinson]

Magnus,

The plugin has very minimal setup requirements. Using the xmlrpc plugin
with ticket updating enabled, a user with permissions to call the xmlrpc
methods, and connectivity from the jenkins server to your trac
installation's xmlrpc endpoint.

Can you describe your trac and xmlrpc plugin versions and your
configuration details?

Brent

-- 
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://groups.google.com/groups/opt_out.

Re: dos2unix in Jenkins

[Brent Atkinson]

Happy to hear you were able to solve your problem.
On Dec 27, 2012 5:08 PM, "El alaoui Mohamed Reda" 
wrote:

> it's okey thank you  very much :)
>
> 2012/12/26 Brent Atkinson 
>
>> Hi,
>>
>> It should be simply a matter of doing the following:
>>
>>
>>- Checkout your working copy
>>- Change to your working copy directory
>>- Find all the files named *.sh and set the svn property
>>'svn:eol-style' to the value of 'LF'
>>
>> This tells subversion to convert the line endings of the file to contain
>> only linefeeds upon checkout, regardless of the type of system it is
>> checked out to. Because scripts are for linux/unix anyway this setting is
>> appropriate. On linux/unix using the command line client the above steps
>> look something like the following:
>>
>> # Checkout the working copy
>> svn co https://hostname.domain/path/to/repo/ my-project
>>
>> # Change to the working copy directory
>> cd my-project
>>
>> # Find all .sh files and set the line ending style to linefeed only
>> find . -type f -name '*.jsp' | xargs svn propset svn:eol-style LF
>>
>> If you're not using the command line you can just google for 'setting
>> svn:eol-style ' and use the instructions to set the
>> property to 'LF' for linux/unix files.
>>
>> Good luck,
>>
>
>
>
> --
>
> *Mohamed Reda, El alaoui*
>
> *
> *
>

Re: dos2unix in Jenkins

[Brent Atkinson]

Hi,

It should be simply a matter of doing the following:


   - Checkout your working copy
   - Change to your working copy directory
   - Find all the files named *.sh and set the svn property 'svn:eol-style'
   to the value of 'LF'

This tells subversion to convert the line endings of the file to contain
only linefeeds upon checkout, regardless of the type of system it is
checked out to. Because scripts are for linux/unix anyway this setting is
appropriate. On linux/unix using the command line client the above steps
look something like the following:

# Checkout the working copy
svn co https://hostname.domain/path/to/repo/ my-project

# Change to the working copy directory
cd my-project

# Find all .sh files and set the line ending style to linefeed only
find . -type f -name '*.jsp' | xargs svn propset svn:eol-style LF

If you're not using the command line you can just google for 'setting
svn:eol-style ' and use the instructions to set the
property to 'LF' for linux/unix files.

Good luck,

Brent

On Tue, Dec 25, 2012 at 3:32 PM, El alaoui Mohamed Reda <
inforedas...@gmail.com> wrote:

> i'm using subversion but i don't understand how i can make it in jenkins
> please !!
>
> can you explain me !!!
>
>
> 2012/12/25 Brent Atkinson 
>
>> roperty
>
>
>
>
> --
>
>  *Mohamed Reda, El alaoui*
>
> *
> *
>

Re: dos2unix in Jenkins

[Brent Atkinson]

Are you using subversion to checkout the project? If so, you might just
consider setting the svn:eol property on those files to 'LF' so they always
have Unix line endings on checkout.
On Dec 25, 2012 6:38 AM, "El alaoui Mohamed Reda" 
wrote:

> thanks Tomi :)
>
> 2012/12/22 domi 
>
>> you could use ANT with the fixCRLF task:
>> http://ant.apache.org/manual/Tasks/fixcrlf.html
>>
>>
>> >  eol="lf" eof="remove" />
>>
>> /Domi
>>
>>
>> On 20.12.2012, at 20:34, El alaoui Mohamed Reda 
>> wrote:
>>
>> No response ? <344.gif><344.gif><344.gif><344.gif>
>>
>> 2012/12/19 El alaoui Mohamed Reda 
>>
>>> Hello
>>>
>>>
>>> i have a Jenkins installed in Windows and i have a project where i have
>>> a lot of script file .sh i
>>>
>>> so must do dos2unix in commande Ligne for all the file to convert for
>>> windows forme to unix forme
>>> i ask you if i can have a plugin or a windows script to convert all file
>>> in the Build Time
>>>
>>> thanks
>>>
>>
>>
>>
>> --
>>
>>  *Mohamed Reda, El alaoui*
>>
>> *
>> *
>>
>>
>>
>
>
> --
>
>  *Mohamed Reda, El alaoui*
>
> *
> *
>