Feature/basic check

[srbarrios]

What does this PR do?

This new option will allow us to implement the first step to reduce the amount of poolling we do to GitHub in Jenkins CI.

https://github.com/SUSE/spacewalk/issues/6411

The idea is to take advantage of the return code, which will let us know if exist any pending pr, no matter the context or branch, to have an unique Jenkins pipeline pooling to github periodically, and once we have a pending PR, only then execute all the pipelines to run the different checks of PRs. Hopefully we will reduce drastically the number of job executions, and we will have a cleaner history in the childs, as allways they will run, they will have a pending pr to process.

Please @MalloZup @juliogonzalez take a look on that one. Thanks!

[srbarrios]

To be honest, I had the same feeling. I realize about it when I tried to play with options to make it somehow available.. We need that, but inside an option doesn't look the best place to have it. What about another command, but using same backend?

So, the main idea is to have exactly the same output --check option has, but without the need of pass a context or branch to check, but checking for everything pending. We want that, so we don't need a pipeline for each kind of context, but a main pipeline that checks something pending and in case of true, only then run the pipelines for each check, reducing the amount of pooling actions we do to github.

[MalloZup]

Historically, the check functionality was already a burden to maintain and an hack. That hack was added because we had rate-limiting issues from GitHub.

Any check middleware /software should go away from gitarro. The existen -c is already not nice. https://github.com/openSUSE/gitarro/issues/159 I am not fully happy about that, but it was due of lack of time. I accepted that pr because i was thinking we will not endup rely on it. ANd then we did . :smile_cat: :face_with_head_bandage: :rofl:

So now back in ourd days and in 2019 is time to don't redo the same error :)

If we have a seperarte project checking PRs etc etc, this project can be seen as plugin.

I like this idea because we could do it in golang or whatever language needed for it. At the end is just a client fetching GitHub API and using the netrc file or other mechanism.

I mean that project could use graphql API which is the new way of GitHub and is more faster and you can limit the rate-limiting.

If we seperate this, we can concentrate more on the core stuff of gitarro, which is more reacting on some events/comments on PR, files, Label and so on

The flow would be

CHECK external software --> gitarro -> test

[srbarrios]

Ok, it will be harder to get time for it. But I understand the concerns, so let's close the PR and think on the proper architecure.

So, just to be clear if I want to check (but not run) if exist a comment or checkbox, or some action, change in code, whatever that will trigger a new test run, in any "context" meaning "test to run", so is 100% coupled with the backend of gitarro. But I should do it without using gitarro backend, from another external software, how do you propose to do @MalloZup :confused: ?

MAIN ISSUE: I want a --check option that don't force me to specify a "context", but check every kind of context pending.

REASON: I have 7 tests to pass in the same PR and currently I have a Jenkins job running periodically (10min) for each kind of test, only to check if there was any change that triggers any of these tests. It rearly happen, then my history inside the Jenkins jobs is plenty of void executions and I can't track the real executions because they are discarded in the "logrotate" of Jenkins. I want a unique Jenkins job that will check periodically and triggers the other jobs ONLY when there is something to do. I can run 7 times the command gitarro with check option specifying each context but that's a waste of resources and too many requests to GitHub when can be done in one.