-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
⚠️ Internal server error. Please contact Coveralls team. / report submission fails for external contributors #217
Comments
Update: Python 3.10 worked on one build and Python 3.9 did not.... Hm. Python 3.10 works:
Python 3.9 fails:
|
Hi @niccokunzmann. Thanks for reporting your issue. I have submitted the behavior, but I have a few more questions: Questions:
|
Hi @afinetooth, thanks for taking this up!
I cannot say that, yet. When changes are made to collective/icalendar#690, I might have more data. I cannot do it as I have write access.
They worked on
I do not have a pattern yet, as there is only one failed run since we fixed it. There will be more, with patience. I restarted the job to see if my authorization might make a difference... https://coveralls.io/builds/68499778 Indeed, this makes a difference. I am the maintainer and I am allowed to submit coverage. External contributors are not allowed. Coveralls submits the report successfully to GitHub: collective/icalendar#690 (comment) I wonder why. I did not expect that. Is this expected behaviour?
Is there some private URL/token for this or is it a human readable URL? Could you provide a template/example? |
Hi @niccokunzmann. TBH I'm a little confused. Let me give some answers and then ask my questions:
I noticed that this build succeeded, but that there was a prior CI run involved, from Jul 07, that left behind one, early submission of the coverage report with So, it looks like coverage reports were sent once for the build, originally, on Jul 07, then sent again, on Jul 09. I'm not sure if both CI builds were successful, or if the first CI build failed and the second one succeeded, and I'm not sure if you're aware of that, or if that triggers any insights. I just wanted to mention it in case it does. An open question for me here though is why the first coverage report for
I'm glad that worked for you, but just to clarify things from the Coveralls side, there is not necessarily anything that would prevent an external contributor from submitting coverage to Coveralls.io. An external collaborator submitting a PR from a fork can expect to at least see a coverage report in the form of a PR Comment coming from Coveralls, as long as the PR they submitted was built in, and sent to Coveralls from, your CI service, with your Coveralls config. Since you are using the Coveralls GitHub Action, the tokens attached to your upload submissions are "special" in the sense that, instead of needing to be the traditional Coveralls Repo Token, they can be the GitHub App token from our Action. And as long as you are not explicitly blocking PRs from forks from leveraging our Action's token, then PRs from external collaborators should be treated like any other on your project. Other access differences that could cause issues or prevent successful builds: The only thing I did notice that could be causing periodic issues---and more with the Web UI than with uploads to our API---is that this Coveralls Repo does not currently have what we refer to as a "repo owner." I will leave out the explanation, and just say that this can cause issues receiving GitHub Status Updates---and sometimes PR Comments as well---but it wouldn't typically cause a But to remove this as a factor, nevertheless, I gave the repo an owner. Interestingly, I tried to make you the owner since I know you are working on the repo, but I couldn't find a Coveralls user account for your GitHub username being used here. I assume this means you are using Coveralls without logging in, which is possible for public / open source repos. None of the other users contributing to this recent PR you mentioned had Coveralls user accounts either, so, in order to make someone the owner at Coveralls, I made this user owner, since they had an active Coveralls session and seemed to belong to many repos from the My confusion: That said, I might be missing something about why you expected this build to fail---so, if you think so, please let me know. For the meantime, I believe we can factor out the committer of any commits being built for this project in CI, and expect them to succeed. As a result, I'd like to know if any patterns do emerge if you continue receiving The fact that this build succeeded: Does at least tell me that each of your constituent uploads has succeeded at one time, which is helpful. For us, a I am somewhat hopeful that giving your repo an owner at Coveralls removes the possibility of that being a factor, which could relate to something I'm overlooking about its role in submissions---like, perhaps there's something token-related in one of the later stages of a build that I'm overlooking that could cause a call to GitHub to hang, leading to a timeout---a Please let me know the next time you get a Alternatively, I'd love to know if the problem clears up after this. |
Thanks for taking so much time!
The contributor started one failing. When I restarted the same, coverage submission worked then. |
My pleasure, @niccokunzmann. On that build, got it. Thanks for the update. And yes, I'll close this and we can reference it or reopen if it happens again. Take care. |
Dear Coveralls team,
I got this message from the coverallsapp/github-action:
Since we are facing this problem for a while now and thought we have found a fix (which now is not a fix), I would like to contact you about this. I wonder: How can this be approached?
See also:
The text was updated successfully, but these errors were encountered: