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.
Related
Since Sunday, I and my co-worker cannot build any Grails project nor even create a new Grails app of any version. We have completely independent development environments.
For example:
$ grails create-app --profile web junk
| Error Error occurred running Grails CLI: Could not find artifact org.grails:grails-bom:pom:4.0.10 in grailsCentral (https://repo.grails.org/grails/core) (Use --stacktrace to see the full trace)
./gradlew dependencies also fails with Could not find org.grails:grails-gradle-model:3.2.13).
The repository repo.grails.org is up, but when I browse it, it is very slow and missing many, many artifacts.
Is their a way to configure build.gradle to fix this? We have several Grails projects using different versions, mostly using the default repository configuration.
There's actually been some discussion here on stackoverflow, but more on a github issue: https://github.com/grails/grails-core/issues/11825
You can certainly read that issue for far more info than makes sense to post here, but the short version is: URL changed unintentionally, temporary workaround is to move to https://repo.grails.org/artifactory/core
I guess we have an official message related to this issue in grails blog - https://grails.org/blog/2021-06-10-grails-wrapper-update.html
I've got a lot of queued Travis-ci.org jobs showing 'Build created successfully" but nothing is happening. It looks like Travis has got itself into a look creating jobs for my last few commits and not processing any of them. How can I clear out these jobs?
OK so I really don't understand what a travis-ci.org 'request' is because the problem was a bad .travis.yml file and once I fixed that, the CI started again. But the 'requests' are still there :-(.
The 'solution' was to install the travis command-line tool which includes 'travis lint' and allowed me to lint my .travis.yml file until it was at least happy. The downside to this is that, on Windows at least, installing the travis tool took a lot of time and a lot of disk space as it instaled Ruby, MinGW and lots of other stuff that I will probably never use again!
But until travis-ci.org/com creates an on-line linter (how hard can it be?), that's what we're stuck with. OTOH, the first step of the travis-ci.org/com build could be to lint the file and complain if it fails - just a suggestion :-).
My Jenkins instance interface broken. I suspect recent plugin update as the cause. However I cannot remember which plugins get updated recently. I need to know so I can rollback plugin version to the previous one.
How to find this information?
Some possible way:
Jenkins log
Retrieving plugins info via Groovy console
In my opinion, the most efficient way is go to the $JENKINS_HOME/plugins directory, then issue command:
ls -alt *.hpi *.jpi
and the most recently update/installed plugins are ranking at the top of the results, hope this helps.
Create a job scheduled to run daily, that logs the plugins and versions. There are several ways to do this, and it seems that none are straightforward or obvious. The method I've settled on simply archives the output file of this command:
curl -kLsS "${JENKINS_URL}pluginManager/api/json?pretty=1&tree=plugins\[shortName,longName,version\]" \
> plugin-list.txt
That give an easily accessible history from the Jenkins web UI. (Or on-disk if you know where to look.)
Diffs comparing previous version(s) left as an exercise for the reader.
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.
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).