Skip to content
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

"Source not available" (unless logged in) #1579

Open
Krinkle opened this issue Sep 5, 2021 · 7 comments
Open

"Source not available" (unless logged in) #1579

Krinkle opened this issue Sep 5, 2021 · 7 comments

Comments

@Krinkle
Copy link

Krinkle commented Sep 5, 2021

When contributors or other people browse the report on pages such as https://coveralls.io/builds/42662541/source?filename=src%2Fassert.js, it says "Source not available".

As repo owner, when logging in to coveralls, I do see the source, but not when logged-out.

I've done a "sync" from the repo settings in case that helped, but it did not seem to make a difference.

Thanks!

@afinetooth
Copy link
Collaborator

afinetooth commented Sep 7, 2021

Hi @Krinkle, this behavior is a security-related feature and is as-designed.

We don't store any source code at Coveralls, not even for open-source repos. Instead, when the user requests a source code file through our Web UI (to review "line-by-line" coverage), we make a real-time request against the Github API, using the current user's API access token. If the user does not have a token that would give them access to the resource, we don't show it.

I understand this particular repo is open-source. Nevertheless, we require the user to have a Github account to access source code. So not exactly the same behavior as Github, but we need the Github check to ensure the user can have access.

Just curious: are you trying to link to a particular file in the context of a training course or similar? If so, the current workaround is to have the user OAuth into Coveralls with their Github account.

@Krinkle
Copy link
Author

Krinkle commented Sep 7, 2021

@afinetooth I could be wrong, but I suspect that the vast majority of people looking at Coveralls pages for open-source projects are casual contributors, who generally have no reason to be logged-in to the Coveralls website. The exception being if they themselves happen to manage a different open source project that also uses Coveralls, and if they changed something on the Coveralls side for that different project recently enough to still be logged-in from when they did that.

As an example, someone with a GitHub account looking to contribute to QUnit on GitHub, and following the "Coveralls" badge linked from the README, or the link from a pull request status or pull request comment, would find themselves on a page like https://coveralls.io/github/qunitjs/qunit or https://coveralls.io/builds/42662457.

When they then try to browse the source to look for areas to write tests for, or to understand which part of their own pull request is lacking coverage, they are greeted with a 404 error that makes it looks like the Coveralls website is broken. I suppose at the very least it could say something like "Please login with your GitHub account to view the coverage map for this file".

However, this would imho still be a rather discouraging and unwelcoming experience as it presumably means people have to accept your privacy policy, and agree to have yet another company store their email address and other profile information, in a way that's linked to their GitHub identity, their use of Coveralls, which projects they browse on Coveralls and when, and their device/geo information, and this is may then be implicitly shared further with the third-party service and storage providers that Coveralls relies on.

There are numerous (generally big, and insolvent) Internet companies that purposely place things like this behind a seemingly-innocuous "Log in with X" barrier because their business model relies on tracking, rather than on paying customers (e.g. you pay with your personal information). I believe Coveralls is not one of those companies. This belief, however, depends on how a company acts when faced with a situation like this.

@afinetooth
Copy link
Collaborator

Hi @Krinkle.

I get everything you're saying here. I have added an enhancement request to our backlog.

Without getting too much into the separate subject, Coveralls does not store anything beyond the user's Github username and email, if associated. We don't do any user tracking, and we don't share any data with any third parties.

I know you addressed that already:

I believe Coveralls is not one of those companies. This belief, however, depends on how a company acts when faced with a situation like this.

Just sharing it here again for those who may be wondering.

Good arguments, all, though. I'm sure it will be well received.

@stale
Copy link

stale bot commented Dec 24, 2022

This issue has been automatically marked for closure because it has not had recent activity. It will be closed if no further activity occurs. If your issue is still active please add a comment and we’ll review as soon as we can. Thank you for your contributions.

@pdurbin
Copy link

pdurbin commented May 8, 2023

Hello, first of all, thank you for Coveralls! We've been using it for years and we're adding a new repo to it.

With regard to not being able to see the source code, I'm seeing some interesting behavior over at IQSS/dataverse-frontend#66

Here I can see code even in an incognito/private window: https://coveralls.io/builds/59676269/source?filename=src%2Fmain%2Fjava%2Fedu%2Fharvard%2Fiq%2Fdataverse%2Fdatavariable%2FVarGroup.java

Here I can only see code if I first log into Coveralls: https://coveralls.io/builds/59669530/source?filename=src%2Fsections%2Fui%2Ftabs%2FTab.tsx

Both repos are open source. I prefer not needing to log into Coveralls.

@afinetooth
Copy link
Collaborator

afinetooth commented May 9, 2023

Hi @pdurbin. The reason for that issue is that your IQSS/dataverse-frontend repo has no owner.
Which you can see in the repo's settings:
https://coveralls.io/github/IQSS/dataverse-frontend/settings

Screenshot 2023-05-08 at 5 15 26 PM

^^ It's actually not as clear as it could be (new ticket added to backlog!), but normally, there would be a username there instead of what looks like a path. It looks like the original owner may have deleted their Coveralls account.

Your repo "owner", BTW, is typically the user who added the repo to Coveralls.io. But, in general, it's the user whose token we leverage to perform general API actions not specific to a given user.

Why is that?:
With respect to our legacy, OAuth App-based Github Integration (which almost everyone is still using because we just opened the beta for our new, Github App-based Github integration last week), every repo needs an owner with a valid Github API token. Not because the repo is private, but simply because a token is a requirement for all Github API requests.

How to fix?:
To fix this quickly, I made your user (pdurbin) the "owner" of the repo, because I could see you're a collaborator and, actually, an Admin. Upon doing that, I was able to see the source file you mentioned without being logged in:
https://coveralls.io/builds/59669530/source?filename=src%2Fsections%2Fui%2Ftabs%2FTab.tsx

Next steps?:
This would be the way to resolve this issue if you encounter it again. Unfortunately, end users are not able to transfer repo ownership in the UI, so you'll have to contact us at support@coveralls.io, but it's something we'll do very quickly for you.

You also have the option of joining the New Github Integration Beta! Just click on Reach out to Support there and we'll follow-up to get you started.

@jpmckinney
Copy link

I found this quite confusing. Could a prompt be added like "Try logging in", or could the message be changed to "Not authorized to view code" – the action the user needs to take is so simple, but I never would have guessed that the problem was that I wasn't logged in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants