-
Notifications
You must be signed in to change notification settings - Fork 13
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
Behave correctly on non-Go repositories #80
Labels
Comments
And importantly, customers should not get billed for non Go projects, even if we had to queue and clone them. |
Related to #73 because we can use the same mechanism to determine if repo is public or private. |
bradleyfalzon
added a commit
that referenced
this issue
Apr 24, 2017
This commit sets up a better framework for ignoring certain GitHub events early, before they're sent to the queue. We don't queue them because some organisations have many non-Go repositories and queuing all those jobs to just be immediately discarded was becoming a little wasteful. In the future, I'm happy for this decision to be reversed. This is implemented in a GitHub specific manner, as it ensured the events would be discarded before a clone of the repository occurred. Resolves #80. Related to #73.
bradleyfalzon
added a commit
that referenced
this issue
Apr 24, 2017
This commit sets up a better framework for ignoring certain GitHub events early, before they're sent to the queue. We don't queue them because some organisations have many non-Go repositories and queuing all those jobs to just be immediately discarded was becoming a little wasteful. In the future, I'm happy for this decision to be reversed. This is implemented in a GitHub specific manner, as it ensured the events would be discarded before a clone of the repository occurred. Resolves #80. Related to #73.
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As a user, I should be able to enable GopherCI on all my repositories, and GopherCI should either not appear in the GitHub Status API at all, or it should never fail.
Currently it fails because on an empty repository (a repository without any go files with a package declaration), go get fails.
If there's a .go file with a package declaration anywhere, this isn't an issue.
Ideally, GopherCI would never be executed at all, but more realistically, we may need to close the repository before we know whether there's Go files there at all. By the time we clone, the status API has already been set.
It may be possible to use GitHub API to check the repositories file list or similar, but this is GitHub specific. It may have its own inconsistencies (we need to ensure it reports the file list at that specific commit - the head ref in this case). This would save bandwidth, not downloading repositories that can't be checked, but we still need to fix the underlying issue for a VCS that isn't GitHub.
EDIT: So I think the approach I'll take is to use the GitHub API (another API call for a PR, but a push contains changed/added/removed files) to determine if Go files were added/changed/removed. If none, we won't touch the status API at all. This would be GitHub specific, so docs for Analyser should be updated to require repositories that have Go code, or handle the scenario more gracefully).
The text was updated successfully, but these errors were encountered: