opensuse / gitarro Goto Github PK

The organisation parameter will run the test only if the user is a part of group on github.

• improved testing with acceptance tests

• use rspec for acceptance tests

• create how to contriubte small doc

• Increase coverage if needed (analyze it)

• find a way to mock github prs https://github.com/octokit/fixtures#how-it-works

https://ci.suse.de/job/manager-prs-schema-migration-pipeline/3947/console

It failed the test at Jenkins (OK), but the PR was not updated: https://github.com/SUSE/spacewalk/pull/2665#pullrequestreview-78753789

As discussed with @MalloZup at IRC:

We need to export the variables, write the VARS file and a write new JSON file with details about the PR to be on --check as well

Right now the VARS file is only written when an actual check was executed when a test was executed (no --check

This useful if at the real test we want to get information about the PR.

However the VARS file is just too simple and some tests will need more stuff such as the list of changes, and maybe even the changes themselves, or the author, time, etc.

So now a .gitarro_pr.json needs to be created created with basically all the information from the PR provided by octokit's client.pull_request and client.pull_request_files.

if therre are conflicts or something, we need to ensure that the branch git is restored or deleted

• rename docker images related stuff.

• Rename all Jenkins jobs to use gitarro (done partially)

https://ci.suse.de/job/manager-prs-changelog/4545/

Right now:

==============================
TITLE_PR: DO NOT MERGE!!! Fake PR to test ruby style checks, NR: 2210
==============================
failure
Cloning into 'spacewalk'...
Warning: Permanently added the RSA host key for IP address '192.30.253.113' to the list of known hosts.
Checking out files:  41% (5690/13874)   
Checking out files:  42% (5828/13874)   
Checking out files:  43% (5966/13874)   
Checking out files:  44% (6105/13874)   
Checking out files:  45% (6244/13874)   
Checking out files:  46% (6383/13874)   
Checking out files:  47% (6521/13874)   
Checking out files:  48% (6660/13874)   
Checking out files:  49% (6799/13874)   
Checking out files:  50% (6937/13874)   
Checking out files:  51% (7076/13874)   
Checking out files:  51% (7091/13874)   
Checking out files:  52% (7215/13874)   
Checking out files:  53% (7354/13874)   
Checking out files:  54% (7492/13874)   
Checking out files:  55% (7631/13874)   
Checking out files:  56% (7770/13874)   
Checking out files:  57% (7909/13874)   
Checking out files:  58% (8047/13874)   
Checking out files:  59% (8186/13874)   
Checking out files:  60% (8325/13874)   
Checking out files:  61% (8464/13874)   
Checking out files:  62% (8602/13874)   
Checking out files:  63% (8741/13874)   
Checking out files:  64% (8880/13874)   
Checking out files:  65% (9019/13874)   
Checking out files:  66% (9157/13874)   
Checking out files:  67% (9296/13874)   
Checking out files:  68% (9435/13874)   
Checking out files:  69% (9574/13874)   
Checking out files:  70% (9712/13874)   
Checking out files:  71% (9851/13874)   
Checking out files:  72% (9990/13874)   
Checking out files:  73% (10129/13874)   
Checking out files:  74% (10267/13874)   
Checking out files:  75% (10406/13874)   
Checking out files:  76% (10545/13874)   
Checking out files:  77% (10683/13874)   
Checking out files:  78% (10822/13874)   
Checking out files:  79% (10961/13874)   
Checking out files:  80% (11100/13874)   
Checking out files:  81% (11238/13874)   
Checking out files:  82% (11377/13874)   
Checking out files:  83% (11516/13874)   
Checking out files:  84% (11655/13874)   
Checking out files:  85% (11793/13874)   
Checking out files:  86% (11932/13874)   
Checking out files:  87% (12071/13874)   
Checking out files:  88% (12210/13874)   
Checking out files:  89% (12348/13874)   
Checking out files:  90% (12487/13874)   
Checking out files:  91% (12626/13874)   
Checking out files:  92% (12765/13874)   
Checking out files:  93% (12903/13874)   
Checking out files:  94% (13042/13874)   
Checking out files:  95% (13181/13874)   
Checking out files:  96% (13320/13874)   
Checking out files:  96% (13397/13874)   
Checking out files:  97% (13458/13874)   
Checking out files:  98% (13597/13874)   
Checking out files:  99% (13736/13874)   
Checking out files: 100% (13874/13874)   
Checking out files: 100% (13874/13874), done.

Already on 'Manager'

Warning: Permanently added the RSA host key for IP address '192.30.253.112' to the list of known hosts.
From github.com:SUSE/spacewalk
 * branch                  Manager    -> FETCH_HEAD
fatal: 'origin/ruby-style-test' is not a commit and a branch 'PR-ruby-style-test' cannot be created from it

ERROR: Repository not found.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
error: Could not fetch remruby-style-test
Fetching origin
Fetching remruby-style-test

ERROR: Repository not found.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

fatal: 'remruby-style-test/ruby-style-test' is not a commit and a branch 'PR-ruby-style-test' cannot be created from it


Inspecting 0 files


0 files inspected, no offenses detected

The test proceeded even if there was an error cloning, and exits with return code 0, so the test is marked as successful at the PR status.

The check option should return 0 or 1 for foundinig on PRs need tests.

Printing Something and then parsing it with perl is not handy, when we use gitarro in other tools.

Run 1 time, after check that gitarro was runned only 1 time.
( this is imporant to ensure the design of gitarro, which is to run only by retrigger)

depends first on this #42 :)

https://github.com/openSUSE/gitarro/blob/master/tests/unit_tests/t_backend.rb#L54
and
https://github.com/openSUSE/gitarro/blob/master/tests/unit_tests/t_backend.rb#L61

This tests use the github api in travis. We need to move this to rspec

It's sometimes handy to re-trigger Jenkins jobs manually, and a convenient way is a magic comment like Salt developers do:

saltstack/salt#41235 (comment)

we need only 3 mandatory options;

Repo
Tests
and Name of the contest

For the -g option, we will store the location on a file so next run we will rerun

• Create a dockerfile, test it and add it to the repo
• Publish docker image to hub
• Upgrade the doc

postifx of file yaml

• postfix TEST0_gitbot.yaml so gitbot.yaml

how to execute

gitbot mytest_gitbot.yml will parse all option from the file

todos:

• Feature

• Documentation

• Tests

gitarro cannot clone private repos

Cloning into '/home/jenkins/jenkins-build/workspace/manager-prs-changelog-pipeline/spacewalk1510069298_71'...
ERROR: Repository not found.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

add a WARNING when --change_since enabled to show that the cache is not being used.

After #47 there seems to be a problem.

When there are no PRs we are now returning 0, which is correct since there were no errors.

However Jenkins does the following:

• If gitarro returned 0, it changes it to 1, so downstream job is not launched.
• If gitarro returned 1, it changes it to 0, so downstream job is launched.

We ned to change this behaviour. A Jenkins job must only fail when there is a problem, and not having PRs with changes is not a failure.

What I propose here is to keeping retur 0 when there are no PRs, and modify the output to include a text that we can easily identify with Jenkins.

Right now the text is:
There are no Pull Requests opened or with changes newer than 3600 seconds

Let's change it to:

[NOPRS] There are no Pull Requests opened or with changes newer than 3600 seconds

When --changed_since >= 0

And

[NOPRS] There are no Pull Requests opened

When --change_since < 0 (in fact this is small bug, since it didn't crashed but showed "or with changes newer than -1 seconds")

So we can easily grep if return code is 0 and determine if there were PRs or not without breaking the jobs (in fact we should configure them to send email when they REALLY break, for example because gitarro is not working -a bug, permission problems, etc...).

In the meantime I will remove --changed_since from the log.

With the refactor we should also check if we are doing this at other places.

it would be nice that the script can have some metadata about the PR that is running on

If somebody want to push a PR from "GINO-"repo to "SPACE" repo, this will not work because gitbot is assuming that the branch already exist, and you create an upstream branch to SPACE, so gitbot can retrieve the branch and switch on it

Figure out how to extrapolate the whole changelog flag and make a standalone test that gitarro will execute like

-t changelog.rb

https://ci.suse.de/job/manager-prs-schema-migration-pipeline/25265/

I'd say this is provoking the failure:

[Run tests oracle] *** Progress: #
[Run tests oracle] Could not populate database.

Shouldn't gitarro produce a log line to inform that the test is failed?

And of course, it should return != 0 so the CI job fails.

Reek is a nice gem for refactoring, analyze the code.
https://github.com/troessner/reek
Would be nice to have a rake task.
And start to fix some warning

At moment the class Backend.rb has to many responsabilities.

We need to split it, in more indipendant classes. (or modules)

• TestExecutor class ( where all test execution operation are done)

• StatusPr class (where we handle all status operation)

• Tasks:

• #54 remove changelog

• #67

• 3

This options is mixing the behaviour.

We should have a test_executor and a trigger/scheduler (utilty/tools that is used on jenkins, for example)

   gb.launch_test_and_setup_status(gb.repo, pr.head.sha,
                                    pr.head.ref, pr.base.ref)
can be

```console
   gb.launch_test_and_setup_status(gb.repo, pr) 

and the rest is readed by method internally

@MalloZup, can you please make a single PR for the refactor and transformation into a gem?

I am trying to add a new functionality, but I see now duplicated code, and don't know where to make the changes anymore.

https://help.github.com/articles/git-automation-with-oauth-tokens/

split main in more convenable way, refractoring it in a class to lib

I would suggest that we start to use ? for distinguish functions/methods that return a false/true.

Like pr_triggered_by_comment? (return a boolean where we check)
and do_test (doesn't return a boolean)

We want to send results for failed tests to the github author of the PR.

At moment we have a monolythic rspec suite.
We need to split this and make it run parallel, so we can improve time and performance of having the tests results

We want to create the dir if the dir doesn't exist.
Create a simple tests for this

rename the var j_status to better name, like test_status or something better 🚀

--branch Manager-3.1 should run only on Manager-3.1 branch

within we can gain splitting job from branches

it happens that if there are PRs with conflicts, the git Fs mess up, we need more testing on that, and add a mechanism to remove the git_dir if this cannot be resolved.

==============================
TITLE_PR: for_testing_pr , NR: 30
==============================
Got triggered by PR_NUMBER OPTION, rerunning on 30


Fetching origin
Fetching remfake_branch


doc/BASICS.md: needs merge
lib/opt_parser.rb: needs merge


.==============================
TITLE_PR: Backend refactoring, NR: 35
==============================
error: you need to resolve your current index first
error: Pulling is not possible because you have unmerged files.
hint: Fix them up in the work tree, and then use 'git add/rm <file>'
hint: as appropriate to mark resolution and make a commit.
fatal: Exiting because of an unresolved conflict.
error: you need to resolve your current index first
From github.com:openSUSE/gitbot
 * [new branch]      backend-refactoring -> rembackend-refactoring/backend-refactoring
 * [new branch]      fake_branch -> rembackend-refactoring/fake_branch
 * [new branch]      master      -> rembackend-refactoring/master
 * [new branch]      refactoring -> rembackend-refactoring/refactoring
 * [new branch]      refactoring-function -> rembackend-refactoring/refactoring-function
 * [new branch]      refactoring_git_op -> rembackend-refactoring/refactoring_git_op
error: Pulling is not possible because you have unmerged files.
hint: Fix them up in the work tree, and then use 'git add/rm <file>'
hint: as appropriate to mark resolution and make a commit.
fatal: Exiting because of an unresolved conflict.
error: you need to resolve your current index first
error: you need to resolve your current index first
error: branch 'PR-backend-refactoring' not found.
==============================
TITLE_PR: Backend refactoring, NR:

Ok for PR 30 is normal that it fails. ( so it is not a bug), and is normal that it fails with conflicts (PR is old)

we should maybe catch that error and print some errors? donno, for later maybe.
functionality is ok

https://ci.suse.de/job/manager-prs-changelog-pipeline/7402/console

Is it maybe returning an in correct return code (0) to the system?

But it does marks the test as failed at the PR: https://github.com/SUSE/spacewalk/pull/2725#pullrequestreview-79817891

It is time to add a logger utility to gitarro.

In testing mode we will enable the debug status, otherwise just info for user mode

https://ruby-doc.org/stdlib-2.1.0/libdoc/logger/rdoc/Logger.html

we can explore whenever just for giving people a possibility to use gitarro without jenkins.

Whenever will use the crontab and update this, we need only then to also give an example how to use gitarro with a webserver like webrick for updating the weburl

when we are fetching to much for new changes on PRs

We need to find a longterm solution for rate-limiting problem.

some experimental ideas ( since it is hackweek)

https://hackweek.suse.com/16/projects/gitarro-meet-elixir

My goal, is to learn elixir and add some cool feature to gitarro ( as 3rdy party tool, without touching the engine/core of gitarro)

• global fetching of pr with custom filter (and trigger to workersd
• webserver
• worker/scheduler architecture
  ...

I'm having some issues with gitarro on this PR: https://github.com/SUSE/spacewalk/pull/2515

It seems that gitarro starts the execution for that PR but then get some exception and the PR gets stuck in pending state.

Either running a manual rerun command or force pushing the PR to recreate last commit don't work. It leads into the same problem again.

I've caught this exception on Jenkins during gitarro execution: https://ci.suse.de/view/Manager/view/Manager-prs/job/manager-prs-backend_psql-pipeline/219/console

Using shallow clones will remove/refactor the code and we will remove the mandatory G option.

Additionally we will be more safe, avoiding conflict errors and artifacts. since we will remove

would be nice to have a specific filepath for pr that will modify this paths, and just ingnore, this could be usefull to skip tests

error: Pulling is not possible because you have unmerged files.
hint: Fix them up in the work tree, and then use 'git add/rm <file>'
hint: as appropriate to mark resolution and make a commit.
fatal: Exiting because of an unresolved conflict.

In this situation gitarro exists (correct) with a return value !=0 (correct), but it does not show any error or updates the PR test status at GitHub, leaving it as 'pending' forever.