I develop in Rails, keep my code in Github, use CircleCI for testing, and now I've been trying to introduce Coveralls in the picture.
I've set these settings in Coveralls:
I added the coveralls gem:
And I set up spec_helper.rb as instructed in Coveralls' documentation:
What is working:
CircleCi sends coverage information to Coveralls, and I can see the coverage reports.
What is not working: Coveralls doesn't send the pull request status so I can't see in Github whether a PR meets the coverage expectations as shown here in one of their ads:
If anyone went through the Coveralls-CircleCI setup, I would really appreciate some pointers on this.
I faced the same issue and in my case the problem was that I invoked coveralls from a place where the git command did not work.
So I simply moved the .coverage file to the top of the repo prior to invoking coveralls and it fixed the problem.
Related
When I run my code from git repo,using jenkins tool,actual code is not getting executed but only remote repository is getting cloned into my system.
Is it the expected behaviour,if it is please help me how can I execute the actual code?
According to my knowledge code should be executed,why its not happening,please help me in this regard.
I just cannot hook up the automatic update of coveralls.io to my Travis-CI build. All works fine if I execute the scripts on my machines. Here is the last message from the build log:
Submitting coverage to coveralls.io...
Coverage submitted!
Couldn't find a repository matching this job.
'url'
The command "python travis-ci/run.py" exited with 0.
Any hints or suggestions would be highly appreciated.
Best, Philipp
Make sure the TRAVIS, TRAVIS_JOB_ID and TRAVIS_BRANCH environment variables are defined when calling coveralls.
If you're using Tox for example, an extra step is needed as described in the coveralls-python readme.
This question is older, but the current problems show the same error. (And Google finds this too :-))
There were issues opened about it in node-coveralls and coveralls-public (and one more) repositories. It appeared, that Coveralls got accidentally blocked by Travis.
Although the problem was supposed to be fixed, as the comments on the second issue suggest, it occurred again. I myself could upload a new report neither from my machine, nor from Travis. I switched from Coveralls to Codecov.
I just wanted to give Archiva a try, but stumpled over some behaviour very quickly.
So, I downloaded the current release (1.3.6) on my Kubuntu machine, extracted it, started it via ./archiva console, put the archiva repository into the mirrors section in mavens settings.xml and made a maven build.
Everything seemed fine so far, I was able to browse the Archiva repository and saw all the artifacts of my build.
But when I type anything in the search box, I don't get results. For example I see the artifact with the id junit, but when I type junit in the search, it tells me that no results were found.
The documentation states that files are indexed after download, so what else may I have done wrong?
Does junit is an artifact of your build ?
It was probably already locally in your repository so no need to download tru Archiva that's why it's not here.
Note last version 1.4* download index from central repository and display result for search.
The 1.4-M4 (not yet released but I hope soon) will download the artifact too to show more details.
Before anyone guns me down..I have looked at all the messages that has this error but they seem to manifest from a different problem,I couldn't get any substantial information. Following are the errors I'm running into in the git polling log...
I don't have a clue regarding error #1,please provide inputs
For this,I read on other questions that $GERRIT_REFSPEC gets filled in dynamically when there is a gerrit trigger but i don't understand why I keep seeing this in the git poll log. How can I fix this ?
Error messages:
ERROR: Problem fetching from origin / origin - could be unavailable. Continuing anyway
hudson.plugins.git.GitException: Command "/usr/bin/git fetch -t ssh://company.com:29418/platform/vendor/proprietary/mla.git $GERRIT_REFSPEC" returned status code 128:
stdout:
stderr: fatal: Couldn't find remote ref $GERRIT_REFSPEC
Go to the Job's Configure page and search to check This build is parameterized box.
Then set Name to GERRIT_REFSPEC
and Default value to refs/heads/master.
It took me some time to search for how to add this string parameter mentioned in the Gerrit Trigger plugin manual. I use Jenkins 1.567 with Gerrit Trigger 2.11.1.
As of May 2016, this error may be result of fix for SECURITY-170 introduced in Jenkins 2.3 or 1.651.2.
From wiki:
In a May 2016 security advisory, a vulnerability was announced (SECURITY-170 / CVE-2016-3721) whereby attackers could potentially exploit the fact that certain Jenkins plugins allow the definition of arbitrary build parameters — which are in turn injected into the build envirionment.
The fix for this issue — which was first included in Jenkins versions 1.651.2 and Jenkins 2.3 — means that only build parameters that have been explicitly defined in a job's configuration will be available by default at build time. Any other arbitrary parameters added to a build by plugins will not be available by default.
As there are a number of plugins that rely on the behaviour in older Jenkins versions, upgrading to 1.651.2 or 2.3 means that certain build behaviours may be broken.
One of the affected plugins is the Gerrit Trigger. The issue you should watch for updates is here.
However, please note that the Rado's solution to definine the GERRIT_REFSPEC parameter manually in build config can solve this problem temporarily if you build only one branch from Gerrit.
A workaround is available by adding the following JAVA_ARGS to /etc/default/jenkins on ubuntu
JAVA_ARGS="$JAVA_ARGS -Dhudson.model.ParametersAction.keepUndefinedParameters=true"
You could also add which variables should be allowed
JAVA_ARGS="$JAVA_ARGS -Dhudson.model.ParametersAction.safeParameters=GERRIT_REFSPEC,GERRIT_BRANCH
Looks like you ran a Jenkins Gerrit Trigger build manually? The trigger page says,
Using "Build Now"
[..]
Add a String parameter called GERRIT_REFSPEC with the default value refs/heads/master
https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger
After solving this issue if Jenkins is still not pulling the latest code commit(un-merged) then, need to Add Additional Behaviours -> Strategy for choosing what to build -> Gerrit Trigger
Reference: Thanks to Fabian
I have the problem that the code coverage for some reason aren't presented in Sonar.
The result of the unit tests is performed and showed correctly but not the result of the code coverage. The project is build by Jenkins. I have registered the opencover.profiler.dll file as suggested in some threads but still I get no result. Neither I get any error messages in Jenkins when performing the build.
I would be most grateful for any tips on what to do.
Best regards Dan
I think this happens because your Jenkins service is running as "Local System account", but Sonar is running OpenCover with the -register:user switch under the hoods. You should be able to bypass this either by running the Jenkins service as a regular user account, or patch the Sonar-runner to omit the -register:user switch.
It turned out however that the PDB-files caused the problems. They were included in the repository and were for some reason not recreated by the build in Jenkins. The PDB-files therefor contained the wrong path to the actual code files.
Thanks for the help!
Check for version conflicts between OpenCover and the Gallio plugin.
I found that the later versions of OPenCover (starting with Version 4.0.1229) inserted a new tag in the coverage-report.xml file - which the Gallio plugin could not understand. When I rolled back to an older version of OpenCover (4.0.804) the coverage worked again.
You can find more details on http://sonar.15.n6.nabble.com/coverage-report-xml-is-generated-but-sonar-says-coverage-is-0-td5008850.html
It looks like the Gallio plug-in has been updated, but I haven't pursued that yet (wanted to first confirm that this was the cause of the problem).