Re: net.sf.json.JSONException: Error while setting property=signature type class java.lang.Object
Please also see this thread: http://jenkins.361315.n4.nabble.com/JIRA-JENKINS-15105-Signature-in-hudson-tasks-Maven-MavenInstaller-json-causes-NullPointerException-td4639778.html
net.sf.json.JSONException: Error while setting property=signature type class java.lang.Object
This error occurred since last night. Our nightly builds were fine and local build is working just fine as well. Updating http://development1:443/svn/dev-repos/ispmapping/trunk/mapping-jobs-pgz At revision 6179 no change for http://development1:443/svn/dev-repos/ispmapping/trunk/mapping-jobs-pgz since the previous build ERROR: Ignore Problem expanding maven opts macros org.jenkinsci.plugins.tokenmacro.TokenMacroERROR http://stacktrace.hudson-labs.org/search?query=ERROR: Processing failed due to a bug in the code. Please report this to jenkinsci-us...@googlegroups.comnet.sf.json.JSONException http://stacktrace.hudson-labs.org/search?query=net.sf.json.JSONException: Error while setting property=signature type class java.lang.Object at net.sf.json.JSONObject.toBean(JSONObject.java:577) http://stacktrace.hudson-labs.org/search/?query=net.sf.json.JSONObject.toBeanentity=method at net.sf.json.JSONObject.toBean(JSONObject.java:383) http://stacktrace.hudson-labs.org/search/?query=net.sf.json.JSONObject.toBeanentity=method at net.sf.json.JSONObject.toBean(JSONObject.java:250) http://stacktrace.hudson-labs.org/search/?query=net.sf.json.JSONObject.toBeanentity=method at hudson.tools.DownloadFromUrlInstaller$DescriptorImpl.getInstallables(DownloadFromUrlInstaller.java:151) http://stacktrace.hudson-labs.org/search/?query=hudson.tools.DownloadFromUrlInstaller$DescriptorImpl.getInstallablesentity=method at hudson.tools.DownloadFromUrlInstaller.getInstallable(DownloadFromUrlInstaller.java:54) http://stacktrace.hudson-labs.org/search/?query=hudson.tools.DownloadFromUrlInstaller.getInstallableentity=method at hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:63) http://stacktrace.hudson-labs.org/search/?query=hudson.tools.DownloadFromUrlInstaller.performInstallationentity=method at hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:61) http://stacktrace.hudson-labs.org/search/?query=hudson.tools.InstallerTranslator.getToolHomeentity=method at hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:106) http://stacktrace.hudson-labs.org/search/?query=hudson.tools.ToolLocationNodeProperty.getToolHomeentity=method at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:149) http://stacktrace.hudson-labs.org/search/?query=hudson.tools.ToolInstallation.translateForentity=method at hudson.tasks.Maven$MavenInstallation.forNode(Maven.java:510) http://stacktrace.hudson-labs.org/search/?query=hudson.tasks.Maven$MavenInstallation.forNodeentity=method at hudson.maven.MavenModuleSetBuild.getEnvironment(MavenModuleSetBuild.java:172) http://stacktrace.hudson-labs.org/search/?query=hudson.maven.MavenModuleSetBuild.getEnvironmententity=method at hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:560) http://stacktrace.hudson-labs.org/search/?query=hudson.maven.MavenModuleSetBuild$RunnerImpl.doRunentity=method at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:423) http://stacktrace.hudson-labs.org/search/?query=hudson.model.AbstractBuild$AbstractRunner.runentity=method at hudson.model.Run.run(Run.java:1362) http://stacktrace.hudson-labs.org/search/?query=hudson.model.Run.runentity=method at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:454) http://stacktrace.hudson-labs.org/search/?query=hudson.maven.MavenModuleSetBuild.runentity=method at hudson.model.ResourceController.execute(ResourceController.java:88) http://stacktrace.hudson-labs.org/search/?query=hudson.model.ResourceController.executeentity=method at hudson.model.Executor.run(Executor.java:145) http://stacktrace.hudson-labs.org/search/?query=hudson.model.Executor.runentity=method Caused by: java.lang.NullPointerException http://stacktrace.hudson-labs.org/search?query=java.lang.NullPointerException at net.sf.json.JSONObject$MethodProperty.isWritable(JSONObject.java:311) http://stacktrace.hudson-labs.org/search/?query=net.sf.json.JSONObject$MethodProperty.isWritableentity=method at net.sf.json.JSONObject.toBean(JSONObject.java:429) http://stacktrace.hudson-labs.org/search/?query=net.sf.json.JSONObject.toBeanentity=method ... 16 more project=hudson.maven.MavenModuleSet@c7823[mapping-jobs-pgz] project.getModules()=[hudson.maven.MavenModule@edddb[mapping-jobs-pgz/nl.isprojects.mapping:mapping-jobs-pgz][mapping-jobs-pgz/nl.isprojects.mapping:mapping-jobs-pgz][relativePath:]] project.getRootModule()=hudson.maven.MavenModule@edddb[mapping-jobs-pgz/nl.isprojects.mapping:mapping-jobs-pgz][mapping-jobs-pgz/nl.isprojects.mapping:mapping-jobs-pgz][relativePath:] FATAL: Error while setting property=signature type class java.lang.Objectnet.sf.json.JSONException http://stacktrace.hudson-labs.org/search?query=net.sf.json.JSONException: Error while setting property=signature type class
Re: very similar jobs as separate jobs
On Tue, Jun 19, 2012 at 8:50 PM, Sami Tikka sjti...@gmail.com wrote: So, you have a number of jobs that are mostly identical but there's a little bit that should work differently for them. To me this sounds like a perfect case of multi-configuration job. https://wiki.jenkins-ci.org/display/JENKINS/Building+a+matrix+project Essentially, Jenkins will run your job a number of times but each run will have a different value for an environment variable. You can then vary the build behavior based on the environment variable. This actually sounds good for us? * Is there any way to do inter-matrix-job dependencies - or possibly a way to trigger another build for some of the matrix points? * Will jobs share the same checkout on disk or will a different checkout be created for each point in the matrix? * Can some points in the matrix be hardwired to certain nodes? (for example mac - windows) - bram
very similar jobs as separate jobs
Hello all, We have a lot of jobs which all should start exactly the same way ( i.e. check out these 5 repos, copy this here, this there ) and then a different part per job. We do want these jobs to be *separate* jobs though because each job is building a different application with its own set of tests. How can I set this up easily in jenkins without having to write those first steps over and over again? thx! - bram -- Bram de Jong - CTO SampleSumo BVBA, Wiedauwkaai 23 G, B-9000 Ghent, Belgium Web: http://www.samplesumo.com Twitter: http://twitter.com/SampleSumo Facebook: http://facebook.com/SampleSumo Phone: +32 9 3355925 - Mobile: +32 484 154730
(new here) applying Jenkins on our complex code base
Hello all, I've just read the official jenkins book which gave me some ideas, but I wanted to flesh out my ideas before I start configuring. We have a relatively complex system which looks like this: // old code bases, actively used elsewhere, but not actively changed A - svn repo, updated infrequently, updates take up to 30 minutes due to bad layout B - svn repo, updated fairly frequently, uses things from A // new code bases C - git repo, updated frequently, no dependencies D - svn repo, updated frequently, uses things from A, B and E E - git repo, updated frequently, uses things from A, B, C and D Some facts about these reposities: * For A, B, D and E, the same structure holds: A/Codebase - shared code A/Applications/X - an application A/Applications/Y - an application A/Applications/Z - an application * All applications are C++. * Most of the apps have configurations for building in MS Visual Studio 2008 and/or 2010 * Many of the apps have configurations for building in XCode * A few of the apps have configurations for building with linux makefiles. * All the applications assume that all the A, B, C, D and E repositories are in the same subfolder. I.e. for example code in B uses code from A by refering to it as ../../.././C/Codebase/something.h * We need at least nightly builds for all the applications (- at least 50 apps), CI would be even better Now, this definitely does not translate easily to a simple one project, one repo kind of thing, so while the Jenkins book was interesting, it did leave me wanting a bit! :-) My initial guess on how to solve this: * put each of the repo's in a job that *only fetches* the repo into a shared directory and doesn't do anything else. * use the join plugin to create different pipelines (apps in A only need A, apps in B need A+B, apps in C need A+B+D+C) * use a mac with windows and linux VM, set up windows and linux as slaves * some apps have unit tests using the spendid http://code.google.com/p/googletest/ which I suppose is compatible with Jenkins Some questions: * I would love some feedback on this whole configuration and my plan of attack * Does it make sense to try to use of the parameter-ised builds for building the apps on various compiler/platforms? I'm worrying that each of the jobs that do this will need something special/unique for each platform. * Would it be best to put the master on osx/windows/linux? With the VM system I propose it doesn't really matter who the master is.. * Do you have any hints of things I should read? * All of the apps share/assume the same file structure. Will this get me into as much trouble as I think it will - jenkins being built around the idea of each app having a separate workspace? A lot of questions, ... - Bram -- Bram de Jong - CTO SampleSumo BVBA, Wiedauwkaai 23 G, B-9000 Ghent, Belgium Web: http://www.samplesumo.com Twitter: http://twitter.com/SampleSumo Facebook: http://facebook.com/SampleSumo Phone: +32 9 3355925 - Mobile: +32 484 154730
Re: (new here) applying Jenkins on our complex code base
My initial guess on how to solve this: * put each of the repo's in a job that *only fetches* the repo into a shared directory and doesn't do anything else. I'd think in terms of jobs that build components and applications, not so much in relationships to repositories. The problem is that this would mean 100 different jobs that all do the same thing (i.e. update 5 repositories - one of which is SUPER slow). Each job will have need approx 10GB of HD space to just have the repositories. I.e. the overhead of having each of the 5 repos reproduced for each of the 100+ jobs would be immense. Where the code is in subversion, you might use svn externals to pull the components in instead of anything special in jenkins. But the code is spread in Git and Subversion, not just Subversion. It's a bit of a mixture. Also, there is no way I can reorganize things: reorganizing the structure would mean fixing the build scripts/projects for at leadst 100 applications on 5 different platforms (if you count various version of visual studio as platforms)! It is a good idea to give the slaves labels that reflect the build capabilities and restrict the jobs to labels rather than specific nodes so it is easy to expand the pool for more capacity. Duly noted! I'd start with jobs that approximate whatever you are doing manually. Aside from having fewer surprises, you want developers to be able to do their own test builds before committing and have the same thing happen in the integration run. What I described in my email is exactly what we do: 1. make a super folder 2. check out the 5 repos in there 3. all the apps in those 5 repos now build We don't create a new super folder for each application. * Would it be best to put the master on osx/windows/linux? With the VM system I propose it doesn't really matter who the master is.. I'd run it on linux since it is probably the best-tested platform. Duly noted! * All of the apps share/assume the same file structure. Will this get me into as much trouble as I think it will - jenkins being built around the idea of each app having a separate workspace? Yes, with the possible exception of svn externals, you'll need to arrange for each job to archive its build results and for anything else that needs them to copy them wherever they need to be. It is probably possible to make jenkins leave the file structure alone and do builds that just happen to work because needed components are already there, but it seems like a really bad idea and doesn't mesh well with distributed build farms. Hmm, so this is *definitely* going to get me into trouble... - bram
