I'm trying to setup Buildbot in my organization but have a problem with the SVNPoller.
Whenever the subversion repository changes the SVNPoller correctly keeps recognizes this but then fails with the following errors message:
SVNPoller failed [Failure instance: Traceback: : changes.project may not be NULL
I'm pretty sure that I made a mistake but this error message just doesn't really help, so any help is appreciated.
master.cfg:
svn_poller = SVNPoller(
svnurl=source_code_svn_url,
pollinterval=60*10, # seconds
svnuser='job_guest',
svnpasswd='job_guest',
svnbin='/usr/bin/svn'
)
c['change_source'] = [ svn_poller ]
twistd.log
2010-11-11 14:24:01+0100 [-] SVNPoller polling
2010-11-11 14:24:03+0100 [-] svnPoller: _process_changes 34177 .. 34178
2010-11-11 14:24:03+0100 [-] Adding change revision 34178
2010-11-11 14:24:03+0100 [-] adding change, who doberkofler, 1 files, rev=34178, branch=None, repository=http://10.43.1.11/svn/job/ljs_app/trunk, comments test, category None, project None
2010-11-11 14:24:03+0100 [-] SVNPoller failed [Failure instance: Traceback: <class 'pysqlite2.dbapi2.IntegrityError'>: changes.project may not be NULL
/usr/lib/python2.5/site-packages/twisted/internet/defer.py:312:_startRunCallbacks
/usr/lib/python2.5/site-packages/twisted/internet/defer.py:328:_runCallbacks
/usr/lib/python2.5/site-packages/twisted/internet/defer.py:289:_continue
/usr/lib/python2.5/site-packages/twisted/internet/defer.py:285:unpause
--- <exception caught here> ---
/usr/lib/python2.5/site-packages/twisted/internet/defer.py:328:_runCallbacks
/usr/lib/python2.5/site-packages/buildbot/changes/svnpoller.py:504:submit_changes
/usr/lib/python2.5/site-packages/buildbot/changes/manager.py:114:addChange
/usr/lib/python2.5/site-packages/buildbot/master.py:1146:addChange
/usr/lib/python2.5/site-packages/buildbot/db/connector.py:308:addChangeToDatabase
/usr/lib/python2.5/site-packages/buildbot/db/connector.py:212:runInteractionNow
/usr/lib/python2.5/site-packages/buildbot/db/connector.py:237:_runInteractionNow
/usr/lib/python2.5/site-packages/buildbot/db/connector.py:326:_txn_addChangeToDatabase
/usr/lib/python2.5/site-packages/buildbot/db/dbspec.py:105:execute
]
2010-11-11 14:34:01+0100 [-] SVNPoller polling
I found what caused the error: when using SVNPoller it is imeperative to also set the project parameter!
svn_poller = SVNPoller(
project='project',
svnurl=source_code_svn_url,
pollinterval=60*10, # seconds
svnuser='job_guest',
svnpasswd='job_guest',
svnbin='/usr/bin/svn'
)
c['change_source'] = [ svn_poller ]
Indeed, if you are using 0.8 or higher, they require you to specify a project even if you don't want to; since there is no default.
Just add the project = 'myproject' in the poller, as the other user suggested too, and you should be good to go.
Related
I have an open source scala project (https://github.com/lucidsoftware/xtract). The build on travis-ci consistently hangs while running tests, for both scala 2.11 and 2.12. Sometimes it hangs after compiling and before any output from tests, other times it hangs in the middle of running tests. I have tried several iterations of changing the travis, inclding trying with and without sudo: false, different versions of sbt, splitting up the sbt commands in different ways, using both oraclejdk8 and openjdk8, etc.
Am I doing something wrong or is this a bug?
Sample failure: https://travis-ci.org/lucidsoftware/xtract/jobs/280974227
My .travis.yml:
language: scala
scala:
- 2.11.11
- 2.12.3
jdk:
- openjdk8
dist: trusty
sudo: false
cache:
directories:
- $HOME/.ivy2/cache
- $HOME/.sbt/
after_success:
- sbt ++$TRAVIS_SCALA_VERSION package
- |
if [ -n "$TRAVIS_TAG" ] || ([ "$TRAVIS_PULL_REQUEST" == false ] && [ "$TRAVIS_BRANCH" == master ])
then
mkdir ~/.pgp
echo $PGP_PUBLIC | base64 --decode > ~/.pgp/pubring
echo $PGP_SECRET | base64 --decode > ~/.pgp/secring
echo "Publishing snapshot"
sbt ++$TRAVIS_SCALA_VERSION xtract/publishSigned xtractTesting/publishSigned
fi
deploy:
api_key: $GITHUB_AUTH
file:
- xtract-core/target/**/*.jar
- testing/target/**/*.jar
file_glob: true
provider: releases
skip_cleanup: true
on:
tags: true
install: sbt ++$TRAVIS_SCALA_VERSION update
before_cache:
#Avoid unncessary cache updates
- find $HOME/.ivy2 -name "ivydata-*.properties" -print -delete
- find $HOME/.sbt -name "*.lock" -print -delete
EDIT
Failure with -debug option on sbt: https://travis-ci.org/lucidsoftware/xtract/jobs/281081862
The last thing it does is
[debug] Running TaskDef(com.lucidchart.open.xtract.DefaultXmlReadersSpec, specs2 Specification fingerprint, false, [SuiteSelector])
Edit 2
Some notes. This project has multiple subprojects. The build pauses while running tests, and the test are in their own project, because they depend on both the core code, and an a separate sub-project for specs2 matchers specific to the project.
It's a 10min compiler timeout. Maybe the memory limits cause too much swapping.
-Xms2048M
-Xmx2048M
-Xss6M
-XX:MaxPermSize=512M
I think I've finally figured out what was going on.
I was able to reproduce the problem in the travisci/ci-garnet:packer-1512502276-986baf0 docker container. Although to get sbt running I had to find and install the sbt-launch.jar for version 1.1.1 because the installed bootstrapper doesn't work for any version 1.0 or higher. I deleted several folders from the home folder with stuff for other languages to free disk space for downloading artifacts.
After it stalled I took a thread dump of the java process (by sending it a QUIT signal).
The output included this:
Found one Java-level deadlock:
=============================
"specs2-6":
waiting to lock monitor 0x00007fc6a4b9fb68 (object 0x00000000997e39f0, a sbt.internal.inc.classpath.ClasspathFilter),
which is held by "specs2-3"
"specs2-3":
waiting to lock monitor 0x00007fc6d0df7298 (object 0x0000000098f700b0, a sbt.internal.inc.classpath.ClasspathUtilities$$anon$1),
which is held by "specs2-6"
So I knew there was a deadlock which was preventing it from progressing.
After some googling I found a bug for mockito (https://github.com/mockito/mockito/issues/1067).
A workaround is to disable parallelExecution for tests.
I got the same issue. Add to your build.sbt
logLevel := Level.Debug
so that you can use the log-debug to check what is going in on. In my case sbt was looking for
sbt-chain: module revision found in cache: com.fasterxml.jackson#jackson-parent;2.8
[debug] tried /home/travis/.ivy2/local/com.fasterxml.jackson/jackson-bom/2.8.11/jars/jackson-bom.jar
[debug] tried https://repo1.maven.org/maven2/com/fasterxml/jackson/jackson-bom/2.8.11/jackson-bom-2.8.11.jar
[debug] CLIENT ERROR: Not Found url=https://repo1.maven.org/maven2/com/fasterxml/jackson/jackson-bom/2.8.11/jackson-bom-2.8.11.jar
[debug] tried /home/travis/.sbt/preloaded/com.fasterxml.jackson/jackson-bom/2.8.11/jars/jackson-bom.jar
[debug] tried file:////home/travis/.sbt/preloaded/com/fasterxml/jackson/jackson-bom/2.8.11/jackson-bom-2.8.11.jar
[debug] tried https://repo1.maven.org/maven2/com/fasterxml/jackson/jackson-bom/2.8.11/jackson-bom-2.8.11.jar
[debug] CLIENT ERROR: Not Found url=https://repo1.maven.org/maven2/com/fasterxml/jackson/jackson-bom/2.8.11/jackson-bom-2.8.11.jar
When I start play scala production mode that throw this kind of error please any one give me the clear idea..
F:\New_CMS\trunk\server\cms>activator start
[info] Loading project definition from F:\New_CMS\trunk\server\cms\project
[info] Set current project to cms (in build file:/F:/New_CMS/trunk/server/cms/)
[info] Wrote F:\New_CMS\trunk\server\cms\target\scala-2.11\cms_2.11-1.0-SNAPSHOT.pom
Starting server. Type Ctrl+D to exit logs, the server will remain in background
The input line is too long.
The syntax of the command is incorrect.
Follow these steps as a Windows solution:
activator stage in the command line
Copy the stage directory from target\universal\stage to c:\stage to avoid issues with long file paths
To avoid the Bad Application Path issues just create a new .bat file with the following (my project is called proj): set PROJ_OPTS="-Dconfig.file=../conf/application.conf" proj.bat
Note: change PROJ_OPTS to YOURPROJECTNAME_OPTS and proj.bat to yourprojectname.bat
I'm getting stack traces when a ScalaTest test fails in SBT. I've tried set traceLevel in Test := -1 at the SBT prompt, tried changing things in the build.sbt file, etc., but nothing seems to help.
What I'd like to get rid of is this:
> test
[info] TestWritingFunctions:
[info] - threeSquares examples *** FAILED ***
[info] scala.NotImplementedError: an implementation is missing
[info] at scala.Predef$.$qmark$qmark$qmark(Predef.scala:252)
[info] at TestWritingFunctions$$anonfun$1.apply$mcV$sp(WritingFunctions.scala:17)
[info] at TestWritingFunctions$$anonfun$1.apply(WritingFunctions.scala:16)
[info] at TestWritingFunctions$$anonfun$1.apply(WritingFunctions.scala:16)
[info] at org.scalatest.Transformer$$anonfun$apply$1.apply(Transformer.scala:22)
[info] at org.scalatest.Transformer$$anonfun$apply$1.apply(Transformer.scala:22)
[info] at org.scalatest.OutcomeOf$class.outcomeOf(OutcomeOf.scala:85)
[info] at org.scalatest.OutcomeOf$.outcomeOf(OutcomeOf.scala:104)
[info] at org.scalatest.Transformer.apply(Transformer.scala:22)
[info] at org.scalatest.Transformer.apply(Transformer.scala:20)
[info] ...
As you can see, the test is failing because I used the new ??? construct as a placeholder, but since I know there's a placeholder there, I'd just like a *** FAILED *** message without all the rigamarole. Is that possible?
You can use "-o..." without F or S (i.e, "-o" or "-oD" would give you no stack traces, but not "-oF", "-oS", or "-oDS" would give you a stack trace). That means you'd be suppressing all stack traces. If you specify no reporters at all, you'll get a "-o", which means no stack traces.
If you like the short stack traces in general, but don't want to see them when a NotImplementedError is thrown by ???, you can override withFixture and change NotImplementedError into pending tests:
import org.scalatest._
trait PendingIfUnimplemented extends SuiteMixin { this: Suite =>
abstract override def withFixture(test: NoArgTest): Outcome = {
super.withFixture(test) match {
case Failed(ex: NotImplementedError) => Pending
case other => other
}
}
}
This way you'll still get short, long, or no stack traces for regular failures, whatever you chose, but see (pending) for tests that fail because of ???.
(not authoritative, but since no one else has answered:)
I suspect that traceLevel isn't doing anything because the stack traces are coming from ScalaTest, not from sbt.
sbt does have a logLevel setting which is relevant. Try this:
set logLevel in Test := Level.Warn
But note that this suppresses not only the stack traces, but all of the lines in your example that begin with [info]. Instead, you'll just get the [error] stuff at the end, which does at least have the names of the suites with failing tests.
If you really want to only suppress the stack traces without changing anything else, I think that might not be possible. Looking at http://www.scalatest.org/user_guide/using_the_runner , I see options for making stack traces shorter (-oS) or longer (-oF), but no option for omitting the stack trace altogether.
I'm working with PigLatin, using grunt, and every time I 'dump' stuffs, my console gets clobbered with blah blah, blah non-info, is there a way to surpress all that?
grunt> A = LOAD 'testingData' USING PigStorage(':'); dump A;
2013-05-06 19:42:04,146 [main] INFO org.apache.pig.tools.pigstats.ScriptState - Pig features used in the script: UNKNOWN
2013-05-06 19:42:04,147 [main] INFO org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.MRCompiler - File concatenation threshold: 100 optimistic? false
...
...
--- another like 50 lines of useless context clobbering junk here... till ---
...
...
org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.MapReduceLauncher - Success!
now my like 4 lines of info looking for:
(daemon,*,1,1,System Services,/var/root,/usr/bin/false)
(uucp,*,,,/var/spool/uucp,/usr/sbin/uucico)
(taskgated,*,13,13,Task Gate Daemon,/var/empty,/usr/bin/false)
(networkd,*,24,24,Network Services,/var/empty,/usr/bin/false)
(installassistant,*,25,25,/usr/bin/false)
grunt>
---> obviously if it errors, fine lotsa info helpful, but not when it basically works great.
You need to set the log4j properties.
For example:
$PIG_HOME/conf/pig.properties :
enable:
# log4jconf=./conf/log4j.properties
rename: log4j.properties.template -> log4j.properties
log4j.properties :
set info to error:
log4j.logger.org.apache.pig=info, A
You may also set the Hadoop related logging level as well:
log4j.logger.org.apache.hadoop = error, A
An easy way to do this seems to be to redirect standard error as below.
But it will suppress all errors.
pig -x local 2> /dev/null
Also found that if you remove or rename your hadoop install directory to basically make it inaccessible to pig then all those INFO messages go away. Changing logging levels in hadoop didn't help, just so that you know.
When you start pig, pass it a log4j.properties file with pig -4 <filename>.
In my case there was a log4j.properties in the conf directory and setting the level of the logger named org.apache.pig to ERROR is sufficient to make the logger less verbose.
log4j.logger.org.apache.pig=ERROR, A
pig has debug log level one need to set that in pig.properties file,
# Logging level. debug=OFF|ERROR|WARN|INFO|DEBUG (default: INFO)
#
# debug=INFO
The reason one get large logs on console, e.g. change it to ERROR
I've been trying to install SNA packages but i always get the next errors,
> install.packages("sna")
Installing package(s) into ‘/home/rvaca/R/i486-pc-linux-gnu-library/2.14’
(as ‘lib’ is unspecified)
--- Please select a CRAN mirror for use in this session ---
Loading Tcl/Tk interface ... done
trying URL 'http://cran.cnr.Berkeley.edu/src/contrib/sna_2.2-0.tar.gz'
Content type 'application/x-gzip' length 273329 bytes (266 Kb)
opened URL
==================================================
downloaded 266 Kb
The downloaded packages are in
‘/tmp/Rtmp7iF3Qz/downloaded_packages’
> library(sna)
starting httpd help server ... done
Error in attr(helpObj, "call") <- this.call :
attempt to set an attribute on NULL
Error: package/namespace load failed for ‘sna’
> library("sna")
Error in attr(helpObj, "call") <- this.call :
attempt to set an attribute on NULL
Error: package/namespace load failed for ‘sna’
> library('sna')
Error in attr(helpObj, "call") <- this.call :
attempt to set an attribute on NULL
Error: package/namespace load failed for ‘sna’
What happened? Thanks in advance
vacing
When loading the sna package using library(sna) or require(sna), the function .First.lib() is (still) called. This function is now among the defunct functions in the base package (see ?.First.lib), but that's beside the point.
Looking at the source files for sna, .First.lib() is defined in the file zzz.R and contains the line
ehelp <- help(package="sna")$info[[1]].
This does not work well if getOption("help_type") is not "text". You could, therefore, try setting this option before loading the package to see if that works.
options(help_type="text")
library(sna)
Does this still produce an error?
EDIT
Since the above still gives an error, and since the package has properties that are being phased out (i.e., no namespace, and using .First.lib()), I would recommend contacting the package's maintainer (perhaps with a reference to this question on SO):
packageDescription("sna")$Maintainer
Again, my suspicion is that the problem lies in creating the object ehelp in the .First.lib() function, which is called since there is no package namespace specified.
Ok this is the result of sessionInfo(), (I forgot to comment that i runs it into Eclipse)
> sessionInfo()
R version 2.14.2 (2012-02-29)
Platform: i486-pc-linux-gnu (32-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=en_US.UTF-8
[9] LC_ADDRESS=en_US.UTF-8 LC_TELEPHONE=en_US.UTF-8
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] Cairo_1.5-1 igraph_0.5.5-4 rj_1.0.3-7
loaded via a namespace (and not attached):
[1] rj.gd_1.0.3-3 sna_2.2-0 tools_2.14.2