csMACnz
Build numbers
I would like the coveralls build number to match the one created by AppVeyor. I tried setting the --JobId, like this
packages\coveralls.net.0.6.0\tools\csmacnz.coveralls.exe --opencover -i ./coverage.xml
--jobId %APPVEYOR_BUILD_NUMBER%
but it did't work. Here's the yml.
Refer to the coveralls api, they do not currently support AppVeyor. Once they do I can implement the support correctly for it.
Actually, looking a bit harder, maybe they do: https://coveralls.zendesk.com/hc/en-us/articles/201347419-Coveralls-currently-supports
Maybe you need to add --serviceName using appveyor as the value? I will look into what i need to do to make this a default on appveyor through the auto config if that is the case.
Tried --serviceName appveyor with no luck. Here's the various links
- https://coveralls.io/github/richardschneider/net-ipfs-core
- https://ci.appveyor.com/project/richardschneider/net-ipfs-core/build/0.2.4-ci.7%20(Build%20102)
- https://github.com/richardschneider/net-ipfs-core/blob/master/appveyor.yml
The jobId linking might be reserved for travis only. If you can find any provider for any language using appveyor that works i can add this feature.
I will keep an eye on this issue and report back if i find out anything more.
Ive tried APPVEYOR_BUILD_ID APPVEYOR_BUILD_NUMBER and APPVEYOR_JOB_ID . no difference. either it isn't supported or "appveyor" is the wrong service name. I've raised a ticket for this now,
https://github.com/lemurheavy/coveralls-public/issues/642
I'm going to take another look at this, there were some bugs around jobid for a while, maybe i just need to get the service name right... I may not be correctly setting this when I detect appveyor as the service...
Keeping this ticket open for now
There is definitely an outstanding bug with the service-name value in both 1.0.0 and develop that needs fixing.
Found the reason for part of this at least with why it keeps sending coverall.net for service name. do copy defaults mean I cant check was set (default makes it always set.) the default took priority over the autogenerated value from the provider. Will test if this fixes everything then earmark this for next release.