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

Behave correctly on non-Go repositories #80

Closed
bradleyfalzon opened this issue Apr 9, 2017 · 2 comments
Closed

Behave correctly on non-Go repositories #80

bradleyfalzon opened this issue Apr 9, 2017 · 2 comments
Labels

Comments

@bradleyfalzon
Copy link
Owner

bradleyfalzon commented Apr 9, 2017

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.

root@916823289afa:/go/src/github.com/bf-test/gopherci-itest# go get -t ./...
# cd /go/src/github.com/bf-test/gopherci-itest; git pull --ff-only
You are not currently on a branch. Please specify which
branch you want to merge with. See git-pull(1) for details.

    git pull <remote> <branch>

package github.com/bf-test/gopherci-itest/...: exit status 1

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).

@bradleyfalzon
Copy link
Owner Author

And importantly, customers should not get billed for non Go projects, even if we had to queue and clone them.

@bradleyfalzon
Copy link
Owner Author

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant