"Source not available" (unless logged in)

[Krinkle]

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]

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]

@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]

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.