Repo doesn't update.

[kristoffer-paulsson]

I have run circleci on Angelos-project/angelos-project-errno and it usually upload coverage automatically. But for some reason not on this repo. However build goes just fine.

Try to solve it please.

[afinetooth]

Hi, @kristoffer-paulsson.

Since you don't have any builds at coveralls.io for that project yet, I can't glean any information from them.

Can you please invoke verbose mode on your integration and share the full CI build log with debug output with me?

That will show the exact JSON you're trying to upload to the Coveralls API, as well as any errors encountered, by the API, or with the integration.

Assuming you're using the Coveralls Orb for CircleCI, which uses the node-coveralls integration under the hood, here is how to invoke verbose mode:

Add the following environment variable to your .circleci/config.yml (or to env vars for your project) so that it's available to any/all coveralls steps: NODE_COVERALLS_DEBUG=1

(There is also a verbose option you can pass with the upload command that's documented here. Either method should work.

[kristoffer-paulsson]

Hi, thanks for great work.

I do not use the coveralls Orb. Instead I run the Gradle coverallsJacoco plugin, which works for my other project.

Here is my .circleci/config.yml, maybe it can be activated in verbose mode too:

Java Gradle CircleCI 2.0 configuration file

See: https://circleci.com/docs/2.0/language-java/

version: 2.1

#orbs:

coveralls: @.***

Define a job to be invoked later in a workflow.

See: https://circleci.com/docs/2.0/configuration-reference/#jobs

jobs: build: # Specify the execution environment. You can specify an image from Dockerhub or use one of our Convenience Images from CircleCI's Developer Hub. # See: https://circleci.com/docs/2.0/configuration-reference/#docker-machine-macos-windows-executor docker: # specify the version you desire here - image: cimg/openjdk:16.0.2-node

  # Specify service dependencies here if necessary
  # CircleCI maintains a library of pre-built images
  # documented at https://circleci.com/docs/2.0/circleci-images/
  # - image: circleci/postgres:9.4

working_directory: ~/repo

environment:
  # Customize the JVM maximum heap limit
  JVM_OPTS: -Xmx3200m
  TERM: dumb
# Add steps to the job
# See: https://circleci.com/docs/2.0/configuration-reference/#steps
steps:
  - checkout

  # Download and cache dependencies
  - restore_cache:
      keys:
        - v1-dependencies-{{ checksum "build.gradle.kts" }}
        # fallback to using the latest cache if no exact match is found
        - v1-dependencies-

  - run: gradle dependencies

  - save_cache:
      paths:
        - ~/.gradle
      key: v1-dependencies-{{ checksum "build.gradle.kts" }}

  # run tests!
  - run: gradle build test koverXmlReport
  - run: gradle coverallsJacoco

11 aug. 2022 kl. 19:52 skrev James Kessler @.***>:

Hi, @kristoffer-paulsson https://github.com/kristoffer-paulsson.

Since you don't have any builds at coveralls.io for that project https://coveralls.io/github/angelos-project/angelos-project-errno yet, I can't glean any information from them.

Can you please invoke verbose mode https://docs.coveralls.io/troubleshooting#put-it-in-verbose--v on your integration and share the full CI build log with debug output with me?

That will show the exact JSON you're trying to upload to the Coveralls API, as well as any errors encountered, by the API, or with the integration.

Assuming you're using the Coveralls Orb for CircleCI https://circleci.com/developer/orbs/orb/coveralls/coveralls, which uses the node-coveralls https://github.com/nickmerwin/node-coveralls integration under the hood, here is how to invoke verbose mode https://docs.coveralls.io/troubleshooting#put-it-in-verbose--v:

Add the following environment variable to your .circleci/config.yml (or to env vars for your project) so that it's availabel to any/all coveralls steps: NODE_COVERALLS_DEBUG=1

(There is also a verbose option you can pass with the upload command that's documented here https://circleci.com/developer/orbs/orb/coveralls/coveralls#commands. Either method should work.

— Reply to this email directly, view it on GitHub https://github.com/lemurheavy/coveralls-public/issues/1657#issuecomment-1212299381, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJVAJZXCMEBDMRRSNZSN3MTVYU4VZANCNFSM56FSCDAA. You are receiving this because you were mentioned.

[afinetooth]

Hi, @kristoffer-paulsson.

I see. Well, the issues board for the Coveralls Jacoco Gradle Plugin might be the better place to get support for this issue since we primarily support the Coveralls service and API.

I know a little bit more about specific coveralls integrations that grew up in-house, like: coveralls-ruby, node-coveralls, the Coveralls Github Action and the Coveralls Orb for CircleCI. Also, the new Coveralls Universal Reporter (beta).

Are you getting back a specific error message from the Coveralls API? Like a 400, 422, etc? Such a message will help me determine what the issue might be, between the integration and the API.

If there is no response at all from coveralls.io, I suspect you're not actually submitting a POST request to the https://coveralls.io/api/v1/jobs endpoint. Otherwise, it would respond with one of several HTTP error statuses and/or an error message.

That should be in your CI build log. Let me know.

[kristoffer-paulsson]

Hi, I have requested that a verbose option be made available at that grade plugin. https://github.com/nbaztec/coveralls-jacoco-gradle-plugin/issues/53

12 aug. 2022 kl. 01:58 skrev James Kessler @.***>:

Hi, @kristoffer-paulsson https://github.com/kristoffer-paulsson.

I see. Well, the issues board https://github.com/nbaztec/coveralls-jacoco-gradle-plugin/issues?q=is%3Aissue+is%3Aclosed for the Coveralls Jacoco Gradle Plugin https://github.com/nbaztec/coveralls-jacoco-gradle-plugin might be the better place to get support for this issue this since we primarily support the Coveralls service and API.

I know a little bit more about specific coveralls integrations that grew up in-house, like: coveralls-ruby https://github.com/lemurheavy/coveralls-ruby, node-coveralls https://github.com/nickmerwin/node-coveralls, the Coveralls Github Action https://github.com/marketplace/actions/coveralls-github-action and the Coveralls Orb for CircleCI https://circleci.com/developer/orbs/orb/coveralls/coveralls. Also, the new Coveralls Universal Reporter https://github.com/coverallsapp/coverage-reporter (beta).

Are you getting back a specific error message from the Coveralls API? Like a 400, 422, etc? Such a message will help me determine what the issue might be, between the integration and the API.

If there is no response at all from coveralls.io, I suspect you're not actually submitting a POST to the https://coveralls.io/api/v1/jobs https://coveralls.io/api/v1/jobs endpoint. Otherwise, it would respond with one of several HTTP error statuses and/or an error message.

That should be in your CI build log. Let me know.

— Reply to this email directly, view it on GitHub https://github.com/lemurheavy/coveralls-public/issues/1657#issuecomment-1212602043, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJVAJZX3SEWPP6EDE4C6JJDVYWHRDANCNFSM56FSCDAA. You are receiving this because you were mentioned.

[afinetooth]

Hi @kristoffer-paulsson. Great, thanks. That will help everyone using that plugin (and us to provide support).

In the meantime, can you share the existing CI build log(s) for the builds that seemingly have no response from coveralls? I would like to see if we did get a request (we would have returned some API status response that would appear in your log if so).

Also, if you're familiar with saving artifacts from CircleCI runs that could help us in lieu of a verbose mode: If we can determine that coveralls.io did receive a request from your CI build, then we could gain insight by looking into your LCOV and JSON files. The LCOV file gets exported and saved to some local directory in CI after your tests run, and the JSON file is a form file attachment on your eventual POST to coveralls.io. If you can save those out as artifacts, you could share those files with me.

[kristoffer-paulsson]

Hi, again!

It seems like I currently haven’t configured any artifacts to be saved from my builds. However here are links to my logs from the last build.

https://circleci.com/api/v1.1/project/github/angelos-project/angelos-project-errno/29/output/0/0?file=true&allocation-id=62fac8d37b591166545f1c81-0-build%2F9784F36 https://circleci.com/api/v1.1/project/github/angelos-project/angelos-project-errno/29/output/99/0?file=true&allocation-id=62fac8d37b591166545f1c81-0-build%2F9784F36 https://circleci.com/api/v1.1/project/github/angelos-project/angelos-project-errno/29/output/101/0?file=true&allocation-id=62fac8d37b591166545f1c81-0-build%2F9784F36 https://circleci.com/api/v1.1/project/github/angelos-project/angelos-project-errno/29/output/102/0?file=true&allocation-id=62fac8d37b591166545f1c81-0-build%2F9784F36 https://circleci.com/api/v1.1/project/github/angelos-project/angelos-project-errno/29/output/103/0?file=true&allocation-id=62fac8d37b591166545f1c81-0-build%2F9784F36 https://circleci.com/api/v1.1/project/github/angelos-project/angelos-project-errno/29/output/104/0?file=true&allocation-id=62fac8d37b591166545f1c81-0-build%2F9784F36 https://circleci.com/api/v1.1/project/github/angelos-project/angelos-project-errno/29/output/105/0?file=true&allocation-id=62fac8d37b591166545f1c81-0-build%2F9784F36 https://circleci.com/api/v1.1/project/github/angelos-project/angelos-project-errno/29/output/106/0?file=true&allocation-id=62fac8d37b591166545f1c81-0-build%2F9784F36

15 aug. 2022 kl. 20:18 skrev James Kessler @.***>:

Hi @kristoffer-paulsson https://github.com/kristoffer-paulsson. Great, thanks. That will help everyone using that plugin (and us to provide support).

In the meantime, can you share the existing CI build log(s) for the builds that seemingly have no response from coveralls? I would like to see if we did get a request (we would have returned some API status response that would appear in your log if so).

Also, if you're familiar with saving artifacts from CircleCI runs that could help us in lieu of a verbose mode: If we can determine that coveralls.io did receive a request from your CI build, then we could gain insight by looking into your LCOV and JSON files. The LCOV file gets exported and saved to some local directory in CI after your tests run, and the JSON file is a form file attachment on your eventual POST to coveralls.io. If you can save those out as artifacts, you could share those files with me.

— Reply to this email directly, view it on GitHub https://github.com/lemurheavy/coveralls-public/issues/1657#issuecomment-1215562153, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJVAJZQP553Z7VUIPC6RE33VZKCXFANCNFSM56FSCDAA. You are receiving this because you were mentioned.

[afinetooth]

Hi, @kristoffer-paulsson.

Hmm. Yes, I don't see any response from the Coveralls API, which indicates it didn't receive a POST.

I do see where you've declared coveralls-related environment variables, here in this log:

Using environment variables from project settings and/or contexts:
  COVERALLS_REPO_TOKEN=**REDACTED**
  NODE_COVERALLS_DEBUG=**REDACTED**

And I see you have a coveralls-related "task" (coverallsJacoco command) enumerated in a list of tasks, here in this log:

[...]
> Task :coverallsJacoco
[...]

However, just below that, I also see that only one (1) task was invoked (presumably from that list), and it doesn't say which:

[...]
> Task :coverallsJacoco

BUILD SUCCESSFUL in 4s
13 actionable tasks: 1 executed, 12 up-to-date

What I definitely don't see, that I would expect to, is:

1. Any stdout message, emitted from nearly all coveralls integrations, indicating when a POST is being sent to coveralls.io. In the case of coverallsJacoco, that appears to be this log output:

sending payload to coveralls

OR:

2. Any API response (HTTP status & JSON) from the Coveralls API, that typically appears in your logs like:

200 
{"message":"Job #adbbae7c-9944-48db-8625-a90b97da6517.4","url":"https://coveralls.io/jobs/64975270"}

So, that indicates to me that your integration is not sending a POST request to coveralls.io

Given that, I think the best place to go next for support is the issues board of the coverallsJacoco project.

As a possible lead on what might be happening, I did come across two conditions under which the coverallsJacoco integration would not send its POST to coveralls.io. These are from lines in the main test file:

1. When your coverage report is empty
2. When dry run is true / ON

[kristoffer-paulsson]

Thanks for all support. I had a coverallsJacoco path misconfigured. All is my mistake.

Please erase ticket if possible.

Thanks beforehand Best regards Kristoffer Paulsson

16 aug. 2022 kl. 20:14 skrev James Kessler @.***>:

Hi, @kristoffer-paulsson https://github.com/kristoffer-paulsson.

Hmm. Yes, I don't see any response from the Coveralls API, which indicates it didn't receive (or process) a POST.

I do see where you've declared coveralls-related environment variables, here in this log https://circleci.com/api/v1.1/project/github/angelos-project/angelos-project-errno/29/output/99/0?file=true&allocation-id=62fac8d37b591166545f1c81-0-build%2F9784F36:

Using environment variables from project settings and/or contexts: COVERALLS_REPO_TOKEN=REDACTED NODE_COVERALLS_DEBUG=REDACTED And I see you have a coveralls-related "task" enumerated in a list of tasks, here in this log https://circleci.com/api/v1.1/project/github/angelos-project/angelos-project-errno/29/output/106/0?file=true&allocation-id=62fac8d37b591166545f1c81-0-build%2F9784F36:

[...]

Task :coverallsJacoco [...] However, just below that, I also see that only one (1) task was invoked (presumably from that list), and it doesn't say which:

[...]

Task :coverallsJacoco

BUILD SUCCESSFUL in 4s 13 actionable tasks: 1 executed, 12 up-to-date What I definitely don't see, that I would expect to, is:

An entry, present in nearly all coveralls integrations, indicating when a POST is being sent to coveralls.io - In the case of coverallsJacoco https://github.com/nbaztec/coveralls-jacoco-gradle-plugin, that appears to be this log output https://github.com/nbaztec/coveralls-jacoco-gradle-plugin/blob/32ca81cd5b5f1a71abfe07b20d56bd005f8d30b2/src/main/kotlin/CoverallsReporter.kt#L104: sending payload to coveralls OR:

An API response (HTTP status & JSON) from the Coveralls API, that typically appears in your logs like: 200 {"message":"Job #adbbae7c-9944-48db-8625-a90b97da6517.4","url":"https://coveralls.io/jobs/64975270"} So that indicates to me that your integration is not sending a POST request to coveralls.io

Given that, I think the best place to go next for support is the issues board https://github.com/nbaztec/coveralls-jacoco-gradle-plugin/issues?q=is%3Aissue+is%3Aclosed of the coverallsJacoco https://github.com/nbaztec/coveralls-jacoco-gradle-plugin project.

As a possible lead on what might be happening, I did comes across two conditions under which the coverallsJacoco integration would not send its POST to coveralls.io (from lines in the main test file):

When your coverage report is empty https://github.com/nbaztec/coveralls-jacoco-gradle-plugin/blob/32ca81cd5b5f1a71abfe07b20d56bd005f8d30b2/src/test/kotlin/CoverallsReporterTest.kt#L43 When dry run is true / ON https://github.com/nbaztec/coveralls-jacoco-gradle-plugin/blob/32ca81cd5b5f1a71abfe07b20d56bd005f8d30b2/src/test/kotlin/CoverallsReporterTest.kt#L113 — Reply to this email directly, view it on GitHub https://github.com/lemurheavy/coveralls-public/issues/1657#issuecomment-1216985488, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJVAJZTDPTSU4WONUTR3GW3VZPLBRANCNFSM56FSCDAA. You are receiving this because you were mentioned.