Reviewboard showing only 20 branches of gitlab repository

[korta...@email.cz]

Hello,

I managed to connect to my Gitlab repository and when I am creating new 
review I see the repository allright, I even see the branches and commits 
on them, but the problem is I don't see all the branches.
I only see exactly 20 of them. I am not sure if they are the newest ones or 
by which key they are selected. But I need all of the branches. The worst 
problem is I don't see master.
Is it some known issue? Is there some solution? I am not an experienced Git 
user, so maybe it might be just something trivial... I tested in several 
browsers, everywhere the same behavior.

Gitlab version seems: GitLab Community Edition 12.10.1 

Reviewboard version: 3.0.12

Thanks or any help and sorry if it is a noob question...

-- 
Supercharge your Review Board with Power Pack: 
https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: 
https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
--- 
You received this message because you are subscribed to the Google Groups 
"Review Board Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/reviewboard/307d8c7a-5b4b-4451-bba5-2d8081d11f76%40googlegroups.com.

Re: Reviewboard showing only 20 branches of gitlab repository

[Christian Hammond]

Hi,

Hrm, I was sure we fixed this. At one point, the GitLab API didn't give us
pagination information, but once it did we added support in places. It
looks like branches never got that support.

I'll look into it.

However, I will strongly encourage you to use RBTools
 for posting changes for
review, rather than manually selecting commits in the New Review Request
page. It will give you a lot more flexibility in how you manage your
commits locally and represent them on Review Board, and will avoid having
to push to any centralized place prior to review (making it easier to amend
your commits based on review feedback, rebase them prior to landing, etc.).

Christian

On Tue, May 5, 2020 at 9:07 AM korta...@email.cz  wrote:

> Hello,
>
> I managed to connect to my Gitlab repository and when I am creating new
> review I see the repository allright, I even see the branches and commits
> on them, but the problem is I don't see all the branches.
> I only see exactly 20 of them. I am not sure if they are the newest ones
> or by which key they are selected. But I need all of the branches. The
> worst problem is I don't see master.
> Is it some known issue? Is there some solution? I am not an experienced
> Git user, so maybe it might be just something trivial... I tested in
> several browsers, everywhere the same behavior.
>
> Gitlab version seems: GitLab Community Edition 12.10.1
> 
> Reviewboard version: 3.0.12
>
> Thanks or any help and sorry if it is a noob question...
>
> --
> Supercharge your Review Board with Power Pack:
> https://www.reviewboard.org/powerpack/
> Want us to host Review Board for you? Check out RBCommons:
> https://rbcommons.com/
> Happy user? Let us know! https://www.reviewboard.org/users/
> ---
> You received this message because you are subscribed to the Google Groups
> "Review Board Community" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to reviewboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/reviewboard/307d8c7a-5b4b-4451-bba5-2d8081d11f76%40googlegroups.com
> 
> .
>


-- 
Christian Hammond
President/CEO of Beanbag 
Makers of Review Board 

-- 
Supercharge your Review Board with Power Pack: 
https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: 
https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
--- 
You received this message because you are subscribed to the Google Groups 
"Review Board Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/reviewboard/CAE7VndnoCu7kHjt92V18uWRmgfOdvAcEx6nsaQeD5ctC3BKn%3DQ%40mail.gmail.com.

Re: Reviewboard showing only 20 branches of gitlab repository

[korta...@email.cz]

Hi Christian,

We are trying to make the RBTools work in the meantime, but is there any 
progress in "looking into it" ? :-)

If you say you fixed it, couldn't be the problem, that we use version 
3.0.12? We installed the RB on windows using the Bitnami installer and it 
has already version 3.0.17 as it seems. Would an update help?

Thanks for help

Jirka

Dne čtvrtek 7. května 2020 1:33:54 UTC+2 Christian Hammond napsal(a):
>
> Hi,
>
> Hrm, I was sure we fixed this. At one point, the GitLab API didn't give us 
> pagination information, but once it did we added support in places. It 
> looks like branches never got that support.
>
> I'll look into it.
>
> However, I will strongly encourage you to use RBTools 
>  for posting changes for 
> review, rather than manually selecting commits in the New Review Request 
> page. It will give you a lot more flexibility in how you manage your 
> commits locally and represent them on Review Board, and will avoid having 
> to push to any centralized place prior to review (making it easier to amend 
> your commits based on review feedback, rebase them prior to landing, etc.).
>
> Christian
>
> On Tue, May 5, 2020 at 9:07 AM kort...@email.cz  <
> kort...@email.cz > wrote:
>
>> Hello,
>>
>> I managed to connect to my Gitlab repository and when I am creating new 
>> review I see the repository allright, I even see the branches and commits 
>> on them, but the problem is I don't see all the branches.
>> I only see exactly 20 of them. I am not sure if they are the newest ones 
>> or by which key they are selected. But I need all of the branches. The 
>> worst problem is I don't see master.
>> Is it some known issue? Is there some solution? I am not an experienced 
>> Git user, so maybe it might be just something trivial... I tested in 
>> several browsers, everywhere the same behavior.
>>
>> Gitlab version seems: GitLab Community Edition 12.10.1 
>> 
>> Reviewboard version: 3.0.12
>>
>> Thanks or any help and sorry if it is a noob question...
>>
>> -- 
>> Supercharge your Review Board with Power Pack: 
>> https://www.reviewboard.org/powerpack/
>> Want us to host Review Board for you? Check out RBCommons: 
>> https://rbcommons.com/
>> Happy user? Let us know! https://www.reviewboard.org/users/
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Review Board Community" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to revie...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/reviewboard/307d8c7a-5b4b-4451-bba5-2d8081d11f76%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> Christian Hammond
> President/CEO of Beanbag 
> Makers of Review Board 
>

-- 
Supercharge your Review Board with Power Pack: 
https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: 
https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
--- 
You received this message because you are subscribed to the Google Groups 
"Review Board Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/reviewboard/272ee64d-28a7-4950-a566-662a7ed73bc8%40googlegroups.com.

Re: Reviewboard showing only 20 branches of gitlab repository

[korta...@email.cz]

Hi again,

There is another problem... I tried to create a review request from the 
branches and commits I see and I get
"HTTP 500 INTERNAL SERVER ERROR"

What is wrong? Any idea? Isn't the problem, that our reviewboard is running 
on https and port number 444?

Log for this error:
ERROR 

 - root - Unable to update new review request from commit ID 
6a60ac36244fb185817055e6e9c404106b103260 on repository ID=2: HTTP Error 404: 
Not Found
Traceback (most recent call last):
  File 
"C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\reviews\managers.py",
 line 165, in create
draft.update_from_commit_id(commit_id)
  File 
"C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\reviews\models\review_request_draft.py",
 line 419, in update_from_commit_id
return self.update_from_committed_change(commit_id)
  File 
"C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\reviews\models\review_request_draft.py",
 line 492, in update_from_committed_change
commit = self.repository.get_change(commit_id)
  File 
"C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\scmtools\models.py",
 line 509, in get_change
return hosting_service.get_change(self, revision)
  File 
"C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\hostingsvcs\gitlab.py",
 line 641, in get_change
headers={'Accept': 'text/plain'})
  File 
"C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\hostingsvcs\service.py",
 line 188, in http_get
return self.http_request(url, headers=headers, method='GET', **kwargs)
  File 
"C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\hostingsvcs\service.py",
 line 319, in http_request
response = urlopen(request, context=context)
  File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
line 154, in urlopen
return opener.open(url, data, timeout)
  File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
line 435, in open
response = meth(req, response)
  File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
line 548, in http_response
'http', request, response, code, msg, hdrs)
  File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
line 467, in error
result = self._call_chain(*args)
  File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
line 407, in _call_chain
result = func(*args)
  File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
line 654, in http_error_302
return self.parent.open(new, timeout=req.timeout)
  File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
line 435, in open
response = meth(req, response)
  File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
line 548, in http_response
'http', request, response, code, msg, hdrs)
  File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
line 473, in error
return self._call_chain(*args)
  File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
line 407, in _call_chain
result = func(*args)
  File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
line 556, in http_error_default
raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
HTTPError: HTTP Error 404: Not Found


and


ERROR 

None - jiri.kortanek - /api/review-requests/ - djblets.log.middleware - 
Exception thrown for user jiri.kortanek at 
https://myserver.ad001.mycompany.net:444/api/review-requests/

HTTP Error 404: Not Found
Traceback (most recent call last):
  File 
"C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\django\django\core\handlers\base.py",
 line 112, in get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File 
"C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\django\django\views\decorators\cache.py",
 line 52, in _wrapped_view_func
response = view_func(request, *args, **kwargs)
  File 
"C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\django\django\views\decorators\vary.py",
 line 19, in inner_func
response = func(*args, **kwargs)
  File 
"C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\site-packages\djblets\webapi\resources\base.py",
 line 244, in __call__
request, method, view, api_format=api_format, *args, **kwargs)
  File 
"C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.

Re: Reviewboard showing only 20 branches of gitlab repository

[Christian Hammond]

Hi Jirka,

We've fixed the pagination issue and will have the fix in 3.0.18.

I don't know what's going on in that backtrace, but 3.0.12 is pretty old
now, so it may have been a bug in an older release. Or some change in their
API we're not aware of, or something else getting in the way of access. I
unfortunately don't have enough information to go off of from the
backtrace. Just that the API for fetching a change is returning a HTTP 404.

I'd try upgrading and also make sure there aren't any restrictions on the
user configured in Review Board to authenticate with GitLab.

Christian

On Fri, May 15, 2020 at 6:30 AM korta...@email.cz  wrote:

> Hi again,
>
> There is another problem... I tried to create a review request from the
> branches and commits I see and I get
> "HTTP 500 INTERNAL SERVER ERROR"
>
> What is wrong? Any idea? Isn't the problem, that our reviewboard is
> running on https and port number 444?
>
> Log for this error:
> ERROR
>
>  - root - Unable to update new review request from commit ID 
> 6a60ac36244fb185817055e6e9c404106b103260 on repository ID=2: HTTP Error 404: 
> Not Found
> Traceback (most recent call last):
>   File 
> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\reviews\managers.py",
>  line 165, in create
> draft.update_from_commit_id(commit_id)
>   File 
> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\reviews\models\review_request_draft.py",
>  line 419, in update_from_commit_id
> return self.update_from_committed_change(commit_id)
>   File 
> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\reviews\models\review_request_draft.py",
>  line 492, in update_from_committed_change
> commit = self.repository.get_change(commit_id)
>   File 
> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\scmtools\models.py",
>  line 509, in get_change
> return hosting_service.get_change(self, revision)
>   File 
> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\hostingsvcs\gitlab.py",
>  line 641, in get_change
> headers={'Accept': 'text/plain'})
>   File 
> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\hostingsvcs\service.py",
>  line 188, in http_get
> return self.http_request(url, headers=headers, method='GET', **kwargs)
>   File 
> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\hostingsvcs\service.py",
>  line 319, in http_request
> response = urlopen(request, context=context)
>   File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
> line 154, in urlopen
> return opener.open(url, data, timeout)
>   File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
> line 435, in open
> response = meth(req, response)
>   File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
> line 548, in http_response
> 'http', request, response, code, msg, hdrs)
>   File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
> line 467, in error
> result = self._call_chain(*args)
>   File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
> line 407, in _call_chain
> result = func(*args)
>   File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
> line 654, in http_error_302
> return self.parent.open(new, timeout=req.timeout)
>   File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
> line 435, in open
> response = meth(req, response)
>   File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
> line 548, in http_response
> 'http', request, response, code, msg, hdrs)
>   File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
> line 473, in error
> return self._call_chain(*args)
>   File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
> line 407, in _call_chain
> result = func(*args)
>   File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
> line 556, in http_error_default
> raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
> HTTPError: HTTP Error 404: Not Found
>
>
> and
>
>
> ERROR
>
> None - jiri.kortanek - /api/review-requests/ - djblets.log.middleware - 
> Exception thrown for user jiri.kortanek at 
> https://myserver.ad001.mycompany.net:444/api/review-requests/
>
> HTTP Error 404: Not Found
> Traceback (most recent call last):
>   File 
> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\app

Re: Reviewboard showing only 20 branches of gitlab repository

[korta...@email.cz]

Hi Christian,

Thanks for the ideas, my admin managed to update reviewboard to 3.0.17, but 
no luck.
I found out I am missing the SSH settings, so I created a new one and added 
the public part to our gitlab repository, but that was not it either...

I am running out of ideas... is there some information I can give you so 
you can help me? 

For some reason we were not able to make the RBTools run either.

I would hate to have to look for another tool:(

Dne pondělí 18. května 2020 5:19:48 UTC+2 Christian Hammond napsal(a):
>
> Hi Jirka,
>
> We've fixed the pagination issue and will have the fix in 3.0.18.
>
> I don't know what's going on in that backtrace, but 3.0.12 is pretty old 
> now, so it may have been a bug in an older release. Or some change in their 
> API we're not aware of, or something else getting in the way of access. I 
> unfortunately don't have enough information to go off of from the 
> backtrace. Just that the API for fetching a change is returning a HTTP 404.
>
> I'd try upgrading and also make sure there aren't any restrictions on the 
> user configured in Review Board to authenticate with GitLab.
>
> Christian
>
> On Fri, May 15, 2020 at 6:30 AM kort...@email.cz  <
> kort...@email.cz > wrote:
>
>> Hi again,
>>
>> There is another problem... I tried to create a review request from the 
>> branches and commits I see and I get
>> "HTTP 500 INTERNAL SERVER ERROR"
>>
>> What is wrong? Any idea? Isn't the problem, that our reviewboard is 
>> running on https and port number 444?
>>
>> Log for this error:
>> ERROR 
>>
>>  - root - Unable to update new review request from commit ID 
>> 6a60ac36244fb185817055e6e9c404106b103260 on repository ID=2: HTTP Error 404: 
>> Not Found
>> Traceback (most recent call last):
>>   File 
>> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\reviews\managers.py",
>>  line 165, in create
>> draft.update_from_commit_id(commit_id)
>>   File 
>> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\reviews\models\review_request_draft.py",
>>  line 419, in update_from_commit_id
>> return self.update_from_committed_change(commit_id)
>>   File 
>> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\reviews\models\review_request_draft.py",
>>  line 492, in update_from_committed_change
>> commit = self.repository.get_change(commit_id)
>>   File 
>> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\scmtools\models.py",
>>  line 509, in get_change
>> return hosting_service.get_change(self, revision)
>>   File 
>> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\hostingsvcs\gitlab.py",
>>  line 641, in get_change
>> headers={'Accept': 'text/plain'})
>>   File 
>> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\hostingsvcs\service.py",
>>  line 188, in http_get
>> return self.http_request(url, headers=headers, method='GET', **kwargs)
>>   File 
>> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\hostingsvcs\service.py",
>>  line 319, in http_request
>> response = urlopen(request, context=context)
>>   File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
>> line 154, in urlopen
>> return opener.open(url, data, timeout)
>>   File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
>> line 435, in open
>> response = meth(req, response)
>>   File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
>> line 548, in http_response
>> 'http', request, response, code, msg, hdrs)
>>   File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
>> line 467, in error
>> result = self._call_chain(*args)
>>   File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
>> line 407, in _call_chain
>> result = func(*args)
>>   File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
>> line 654, in http_error_302
>> return self.parent.open(new, timeout=req.timeout)
>>   File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
>> line 435, in open
>> response = meth(req, response)
>>   File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
>> line 548, in http_response
>> 'http', request, response, code, msg, hdrs)
>>   File "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", 
>> line 473, in error
>> return self._call_chain(*args)
>>   File "C:\App\Bitnami\

Re: Reviewboard showing only 20 branches of gitlab repository

[korta...@email.cz]

Update:

When we tested it with a "public" repository on our gitlab server, it 
works. But our repositories needs to be private.

So it seems the problem is somewhere in the recognition of the reviewboard 
as a valid user, even though I filled in all the tokens and keys and user 
credentials...

Rings any bells?

Dne pondělí 18. května 2020 16:47:21 UTC+2 kort...@email.cz napsal(a):
>
> Hi Christian,
>
> Thanks for the ideas, my admin managed to update reviewboard to 3.0.17, 
> but no luck.
> I found out I am missing the SSH settings, so I created a new one and 
> added the public part to our gitlab repository, but that was not it 
> either...
>
> I am running out of ideas... is there some information I can give you so 
> you can help me? 
>
> For some reason we were not able to make the RBTools run either.
>
> I would hate to have to look for another tool:(
>
> Dne pondělí 18. května 2020 5:19:48 UTC+2 Christian Hammond napsal(a):
>>
>> Hi Jirka,
>>
>> We've fixed the pagination issue and will have the fix in 3.0.18.
>>
>> I don't know what's going on in that backtrace, but 3.0.12 is pretty old 
>> now, so it may have been a bug in an older release. Or some change in their 
>> API we're not aware of, or something else getting in the way of access. I 
>> unfortunately don't have enough information to go off of from the 
>> backtrace. Just that the API for fetching a change is returning a HTTP 404.
>>
>> I'd try upgrading and also make sure there aren't any restrictions on the 
>> user configured in Review Board to authenticate with GitLab.
>>
>> Christian
>>
>> On Fri, May 15, 2020 at 6:30 AM kort...@email.cz  
>> wrote:
>>
>>> Hi again,
>>>
>>> There is another problem... I tried to create a review request from the 
>>> branches and commits I see and I get
>>> "HTTP 500 INTERNAL SERVER ERROR"
>>>
>>> What is wrong? Any idea? Isn't the problem, that our reviewboard is 
>>> running on https and port number 444?
>>>
>>> Log for this error:
>>> ERROR 
>>>
>>>  - root - Unable to update new review request from commit ID 
>>> 6a60ac36244fb185817055e6e9c404106b103260 on repository ID=2: HTTP Error 
>>> 404: Not Found
>>> Traceback (most recent call last):
>>>   File 
>>> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\reviews\managers.py",
>>>  line 165, in create
>>> draft.update_from_commit_id(commit_id)
>>>   File 
>>> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\reviews\models\review_request_draft.py",
>>>  line 419, in update_from_commit_id
>>> return self.update_from_committed_change(commit_id)
>>>   File 
>>> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\reviews\models\review_request_draft.py",
>>>  line 492, in update_from_committed_change
>>> commit = self.repository.get_change(commit_id)
>>>   File 
>>> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\scmtools\models.py",
>>>  line 509, in get_change
>>> return hosting_service.get_change(self, revision)
>>>   File 
>>> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\hostingsvcs\gitlab.py",
>>>  line 641, in get_change
>>> headers={'Accept': 'text/plain'})
>>>   File 
>>> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\hostingsvcs\service.py",
>>>  line 188, in http_get
>>> return self.http_request(url, headers=headers, method='GET', **kwargs)
>>>   File 
>>> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\hostingsvcs\service.py",
>>>  line 319, in http_request
>>> response = urlopen(request, context=context)
>>>   File 
>>> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", line 
>>> 154, in urlopen
>>> return opener.open(url, data, timeout)
>>>   File 
>>> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", line 
>>> 435, in open
>>> response = meth(req, response)
>>>   File 
>>> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", line 
>>> 548, in http_response
>>> 'http', request, response, code, msg, hdrs)
>>>   File 
>>> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", line 
>>> 467, in error
>>> result = self._call_chain(*args)
>>>   File 
>>> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", line 
>>> 407, in _call_chain
>>> result = func(*args)
>>>   File 
>>> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", line 
>>> 654, in http_error_302
>>> return self.

Re: Reviewboard showing only 20 branches of gitlab repository

[Christian Hammond]

It doesn't ring any bells. It does sound like a credential/repository
access issue, though. I suspect *something* is preventing that user from
accessing changes on that repository in GitLab's settings. I know other
companies are using private repositories on GitLab with Review Board
without issue.

What's the problem you're hitting with RBTools?

Christian

On Mon, May 18, 2020 at 9:04 AM korta...@email.cz  wrote:

> Update:
>
> When we tested it with a "public" repository on our gitlab server, it
> works. But our repositories needs to be private.
>
> So it seems the problem is somewhere in the recognition of the reviewboard
> as a valid user, even though I filled in all the tokens and keys and user
> credentials...
>
> Rings any bells?
>
> Dne pondělí 18. května 2020 16:47:21 UTC+2 kort...@email.cz napsal(a):
>>
>> Hi Christian,
>>
>> Thanks for the ideas, my admin managed to update reviewboard to 3.0.17,
>> but no luck.
>> I found out I am missing the SSH settings, so I created a new one and
>> added the public part to our gitlab repository, but that was not it
>> either...
>>
>> I am running out of ideas... is there some information I can give you so
>> you can help me?
>>
>> For some reason we were not able to make the RBTools run either.
>>
>> I would hate to have to look for another tool:(
>>
>> Dne pondělí 18. května 2020 5:19:48 UTC+2 Christian Hammond napsal(a):
>>>
>>> Hi Jirka,
>>>
>>> We've fixed the pagination issue and will have the fix in 3.0.18.
>>>
>>> I don't know what's going on in that backtrace, but 3.0.12 is pretty old
>>> now, so it may have been a bug in an older release. Or some change in their
>>> API we're not aware of, or something else getting in the way of access. I
>>> unfortunately don't have enough information to go off of from the
>>> backtrace. Just that the API for fetching a change is returning a HTTP 404.
>>>
>>> I'd try upgrading and also make sure there aren't any restrictions on
>>> the user configured in Review Board to authenticate with GitLab.
>>>
>>> Christian
>>>
>>> On Fri, May 15, 2020 at 6:30 AM kort...@email.cz 
>>> wrote:
>>>
 Hi again,

 There is another problem... I tried to create a review request from the
 branches and commits I see and I get
 "HTTP 500 INTERNAL SERVER ERROR"

 What is wrong? Any idea? Isn't the problem, that our reviewboard is
 running on https and port number 444?

 Log for this error:
 ERROR

  - root - Unable to update new review request from commit ID 
 6a60ac36244fb185817055e6e9c404106b103260 on repository ID=2: HTTP Error 
 404: Not Found
 Traceback (most recent call last):
   File 
 "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\reviews\managers.py",
  line 165, in create
 draft.update_from_commit_id(commit_id)
   File 
 "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\reviews\models\review_request_draft.py",
  line 419, in update_from_commit_id
 return self.update_from_committed_change(commit_id)
   File 
 "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\reviews\models\review_request_draft.py",
  line 492, in update_from_committed_change
 commit = self.repository.get_change(commit_id)
   File 
 "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\scmtools\models.py",
  line 509, in get_change
 return hosting_service.get_change(self, revision)
   File 
 "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\hostingsvcs\gitlab.py",
  line 641, in get_change
 headers={'Accept': 'text/plain'})
   File 
 "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\hostingsvcs\service.py",
  line 188, in http_get
 return self.http_request(url, headers=headers, method='GET', **kwargs)
   File 
 "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\hostingsvcs\service.py",
  line 319, in http_request
 response = urlopen(request, context=context)
   File 
 "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", line 
 154, in urlopen
 return opener.open(url, data, timeout)
   File 
 "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", line 
 435, in open
 response = meth(req, response)
   File 
 "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\python\lib\urllib2.py", line 
>

Re: Reviewboard showing only 20 branches of gitlab repository

[korta...@email.cz]

Hi Christian,

Thanks, I have contacted our GitLab support and hopefully it will have a 
good ending.

The colleague testing the RBTools was using this guide 
https://www.reviewboard.org/docs/rbtools/1.0/workflows/git/#rbtools-workflow-git
But ended with 
CRITICAL: [Error 267] The directory name is invalid
when tried using rbt post

I tried to google around for it, but got nothing usefull...


Dne úterý 19. května 2020 2:21:05 UTC+2 Christian Hammond napsal(a):
>
> It doesn't ring any bells. It does sound like a credential/repository 
> access issue, though. I suspect *something* is preventing that user from 
> accessing changes on that repository in GitLab's settings. I know other 
> companies are using private repositories on GitLab with Review Board 
> without issue.
>
> What's the problem you're hitting with RBTools?
>
> Christian
>
> On Mon, May 18, 2020 at 9:04 AM kort...@email.cz  <
> kort...@email.cz > wrote:
>
>> Update:
>>
>> When we tested it with a "public" repository on our gitlab server, it 
>> works. But our repositories needs to be private.
>>
>> So it seems the problem is somewhere in the recognition of the 
>> reviewboard as a valid user, even though I filled in all the tokens and 
>> keys and user credentials...
>>
>> Rings any bells?
>>
>> Dne pondělí 18. května 2020 16:47:21 UTC+2 kort...@email.cz napsal(a):
>>>
>>> Hi Christian,
>>>
>>> Thanks for the ideas, my admin managed to update reviewboard to 3.0.17, 
>>> but no luck.
>>> I found out I am missing the SSH settings, so I created a new one and 
>>> added the public part to our gitlab repository, but that was not it 
>>> either...
>>>
>>> I am running out of ideas... is there some information I can give you so 
>>> you can help me? 
>>>
>>> For some reason we were not able to make the RBTools run either.
>>>
>>> I would hate to have to look for another tool:(
>>>
>>> Dne pondělí 18. května 2020 5:19:48 UTC+2 Christian Hammond napsal(a):

 Hi Jirka,

 We've fixed the pagination issue and will have the fix in 3.0.18.

 I don't know what's going on in that backtrace, but 3.0.12 is pretty 
 old now, so it may have been a bug in an older release. Or some change in 
 their API we're not aware of, or something else getting in the way of 
 access. I unfortunately don't have enough information to go off of from 
 the 
 backtrace. Just that the API for fetching a change is returning a HTTP 404.

 I'd try upgrading and also make sure there aren't any restrictions on 
 the user configured in Review Board to authenticate with GitLab.

 Christian

 On Fri, May 15, 2020 at 6:30 AM kort...@email.cz  
 wrote:

> Hi again,
>
> There is another problem... I tried to create a review request from 
> the branches and commits I see and I get
> "HTTP 500 INTERNAL SERVER ERROR"
>
> What is wrong? Any idea? Isn't the problem, that our reviewboard is 
> running on https and port number 444?
>
> Log for this error:
> ERROR 
>
>  - root - Unable to update new review request from commit ID 
> 6a60ac36244fb185817055e6e9c404106b103260 on repository ID=2: HTTP Error 
> 404: Not Found
> Traceback (most recent call last):
>   File 
> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\reviews\managers.py",
>  line 165, in create
> draft.update_from_commit_id(commit_id)
>   File 
> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\reviews\models\review_request_draft.py",
>  line 419, in update_from_commit_id
> return self.update_from_committed_change(commit_id)
>   File 
> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\reviews\models\review_request_draft.py",
>  line 492, in update_from_committed_change
> commit = self.repository.get_change(commit_id)
>   File 
> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\scmtools\models.py",
>  line 509, in get_change
> return hosting_service.get_change(self, revision)
>   File 
> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\hostingsvcs\gitlab.py",
>  line 641, in get_change
> headers={'Accept': 'text/plain'})
>   File 
> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\hostingsvcs\service.py",
>  line 188, in http_get
> return self.http_request(url, headers=headers, method='GET', **kwargs)
>   File 
> "C:\App\Bitnami\reviewboardpower

Re: Reviewboard showing only 20 branches of gitlab repository

[Christian Hammond]

That error doesn’t make much sense to me. It sounds like it’s being run
from a directory that was then deleted, or there’s some special characters
or something that something is having trouble with.

I’d like to see more about how you’re using RBTools. Can you go into detail
on your setup, how you’re invoking it?

I’d also like to see the debug output from the invocation that leads to
that error. You can pass --debug as the first parameter to `rbt post`.

Christian


On Tue, May 19, 2020 at 05:46 korta...@email.cz  wrote:

> Hi Christian,
>
> Thanks, I have contacted our GitLab support and hopefully it will have a
> good ending.
>
> The colleague testing the RBTools was using this guide
> https://www.reviewboard.org/docs/rbtools/1.0/workflows/git/#rbtools-workflow-git
> But ended with
> CRITICAL: [Error 267] The directory name is invalid
> when tried using rbt post
>
> I tried to google around for it, but got nothing usefull...
>
>
> Dne úterý 19. května 2020 2:21:05 UTC+2 Christian Hammond napsal(a):
>>
>> It doesn't ring any bells. It does sound like a credential/repository
>> access issue, though. I suspect *something* is preventing that user from
>> accessing changes on that repository in GitLab's settings. I know other
>> companies are using private repositories on GitLab with Review Board
>> without issue.
>>
>> What's the problem you're hitting with RBTools?
>>
>> Christian
>>
>> On Mon, May 18, 2020 at 9:04 AM kort...@email.cz 
>> wrote:
>>
> Update:
>>>
>>> When we tested it with a "public" repository on our gitlab server, it
>>> works. But our repositories needs to be private.
>>>
>>> So it seems the problem is somewhere in the recognition of the
>>> reviewboard as a valid user, even though I filled in all the tokens and
>>> keys and user credentials...
>>>
>>> Rings any bells?
>>>
>>> Dne pondělí 18. května 2020 16:47:21 UTC+2 kort...@email.cz napsal(a):

 Hi Christian,

 Thanks for the ideas, my admin managed to update reviewboard to 3.0.17,
 but no luck.
 I found out I am missing the SSH settings, so I created a new one and
 added the public part to our gitlab repository, but that was not it
 either...

 I am running out of ideas... is there some information I can give you
 so you can help me?

 For some reason we were not able to make the RBTools run either.

 I would hate to have to look for another tool:(

 Dne pondělí 18. května 2020 5:19:48 UTC+2 Christian Hammond napsal(a):
>
> Hi Jirka,
>
> We've fixed the pagination issue and will have the fix in 3.0.18.
>
> I don't know what's going on in that backtrace, but 3.0.12 is pretty
> old now, so it may have been a bug in an older release. Or some change in
> their API we're not aware of, or something else getting in the way of
> access. I unfortunately don't have enough information to go off of from 
> the
> backtrace. Just that the API for fetching a change is returning a HTTP 
> 404.
>
> I'd try upgrading and also make sure there aren't any restrictions on
> the user configured in Review Board to authenticate with GitLab.
>
> Christian
>
> On Fri, May 15, 2020 at 6:30 AM kort...@email.cz 
> wrote:
>
>> Hi again,
>>
>> There is another problem... I tried to create a review request from
>> the branches and commits I see and I get
>> "HTTP 500 INTERNAL SERVER ERROR"
>>
>> What is wrong? Any idea? Isn't the problem, that our reviewboard is
>> running on https and port number 444?
>>
>> Log for this error:
>> ERROR
>>
>>  - root - Unable to update new review request from commit ID 
>> 6a60ac36244fb185817055e6e9c404106b103260 on repository ID=2: HTTP Error 
>> 404: Not Found
>> Traceback (most recent call last):
>>   File 
>> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\reviews\managers.py",
>>  line 165, in create
>> draft.update_from_commit_id(commit_id)
>>   File 
>> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\reviews\models\review_request_draft.py",
>>  line 419, in update_from_commit_id
>> return self.update_from_committed_change(commit_id)
>>   File 
>> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\reviews\models\review_request_draft.py",
>>  line 492, in update_from_committed_change
>> commit = self.repository.get_change(commit_id)
>>   File 
>> "C:\App\Bitnami\reviewboardpowerpack-3.0.12-1\apps\reviewboardpowerpack\htdocs\Lib\site-packages\ReviewBoard-3.0.12-py2.7.egg\reviewboard\scmtools\models.py",
>>  line 509, in get_change
>> return hosting_service.get_change(self, rev

Re: Reviewboard showing only 20 branches of gitlab repository

[Martin Růžek]

Hi,

I'm that person trying to use it on real repository.
I hit this error even during setup-repo command. I passed --debug parameter 
and output looks like this:

*D:\git_repository>rbt setup-repo --debug*
*>>> RBTools 1.0.3*
*>>> Python 2.7.17 (v2.7.17:c2f86d86e6, Oct 19 2019, 20:49:36) [MSC v.1500 
32 bit (Intel)]*
*>>> Running on Windows-10-10.0.17134*
*>>> Home = C:\Users\z003fbrn\AppData\Roaming*
*>>> Current directory = d:\Ruzek\LEIA\Emitter\sitrans-tdl-emitter*
*>>> Command line: rbt setup-repo --debug*
*Enter the Review Board server URL: 
https://czprga99033srv.ad001.siemens.net:444/*
*>>> Running: tf vc help*
*>>> Checking for a Subversion repository...*
*>>> Unable to execute "svn help": skipping SVN*
*>>> Checking for a Git repository...*
*>>> Running: git rev-parse --git-dir*
*>>> Running: git config core.bare*
*>>> Running: git rev-parse --show-toplevel*
*>>> Running: git symbolic-ref -q HEAD*
*Traceback (most recent call last):*
*  File "C:\Program Files 
(x86)\RBTools\bin\..\Python27\Scripts\rbt-script.py", line 11, in *
*load_entry_point('RBTools==1.0.3', 'console_scripts', 'rbt')()*
*  File "C:\Program Files 
(x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\commands\main.py",
 
line 120, in main*
*command.run_from_argv([RB_MAIN, command_name] + args)*
*  File "C:\Program Files 
(x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\commands\__init__.py",
 
line 725, in run_from_argv*
*exit_code = self.main(*args) or 0*
*  File "C:\Program Files 
(x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\commands\setup_repo.py",
 
line 105, in main*
*repository_info, tool = self.initialize_scm_tool()*
*  File "C:\Program Files 
(x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\commands\__init__.py",
 
line 754, in initialize_scm_tool*
*client_name=client_name)*
*  File "C:\Program Files 
(x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\clients\__init__.py",
 
line 803, in scan_usable_client*
*repository_info = tool.get_repository_info()*
*  File "C:\Program Files 
(x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\clients\git.py",
 
line 284, in get_repository_info*
*ignore_errors=True).strip()*
*  File "C:\Program Files 
(x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\clients\git.py",
 
line 1261, in _execute*
*return execute(cmdline, cwd=self._git_toplevel, *args, **kwargs)*
*  File "C:\Program Files 
(x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\utils\process.py",
 
line 155, in execute*
***popen_encoding_args)*
*  File "C:\Program Files (x86)\RBTools\Python27\lib\subprocess.py", line 
394, in __init__*
*errread, errwrite)*
*  File "C:\Program Files (x86)\RBTools\Python27\lib\subprocess.py", line 
644, in _execute_child*
*startupinfo)*
*WindowsError: [Error 267] The directory name is invalid*

If I try post command, report looks like this:

*d:\git_repository>rbt post --debug*
*>>> RBTools 1.0.3*
*>>> Python 2.7.17 (v2.7.17:c2f86d86e6, Oct 19 2019, 20:49:36) [MSC v.1500 
32 bit (Intel)]*
*>>> Running on Windows-10-10.0.17134*
*>>> Home = C:\Users\z003fbrn\AppData\Roaming*
*>>> Current directory = d:\Ruzek\LEIA\Emitter\sitrans-tdl-emitter*
*>>> Command line: rbt post --debug*
*>>> Running: tf vc help*
*>>> Checking for a Subversion repository...*
*>>> Unable to execute "svn help": skipping SVN*
*>>> Checking for a Git repository...*
*>>> Running: git rev-parse --git-dir*
*>>> Running: git config core.bare*
*>>> Running: git rev-parse --show-toplevel*
*>>> Running: git symbolic-ref -q HEAD*
*Traceback (most recent call last):*
*  File "C:\Program Files 
(x86)\RBTools\bin\..\Python27\Scripts\rbt-script.py", line 11, in *
*load_entry_point('RBTools==1.0.3', 'console_scripts', 'rbt')()*
*  File "C:\Program Files 
(x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\commands\main.py",
 
line 120, in main*
*command.run_from_argv([RB_MAIN, command_name] + args)*
*  File "C:\Program Files 
(x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\commands\__init__.py",
 
line 725, in run_from_argv*
*exit_code = self.main(*args) or 0*
*  File "C:\Program Files 
(x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\commands\post.py",
 
line 756, in main*
*client_name=self.options.repository_type)*
*  File "C:\Program Files 
(x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\commands\__init__.py",
 
line 754, in initialize_scm_tool*
*client_name=client_name)*
*  File "C:\Program Files 
(x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\clients\__init__.py",
 
line 803, in scan_usable_client*
*repository_info = tool.get_repository_info()*
*  File "C:\Program Files 
(x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\clients\git.py",
 
line 28

Re: Reviewboard showing only 20 branches of gitlab repository

[Christian Hammond]

Hi Martin,

The error is coming from Git, it seems. Can you run this command from that
directory and see what it says:

git symbolic-ref -q HEAD

Christian


On Fri, May 22, 2020 at 08:51 Martin Růžek  wrote:

> Hi,
>
> I'm that person trying to use it on real repository.
> I hit this error even during setup-repo command. I passed --debug
> parameter and output looks like this:
>
> *D:\git_repository>rbt setup-repo --debug*
> *>>> RBTools 1.0.3*
> *>>> Python 2.7.17 (v2.7.17:c2f86d86e6, Oct 19 2019, 20:49:36) [MSC v.1500
> 32 bit (Intel)]*
> *>>> Running on Windows-10-10.0.17134*
> *>>> Home = C:\Users\z003fbrn\AppData\Roaming*
> *>>> Current directory = d:\Ruzek\LEIA\Emitter\sitrans-tdl-emitter*
> *>>> Command line: rbt setup-repo --debug*
> *Enter the Review Board server URL:
> https://czprga99033srv.ad001.siemens.net:444/
> *
> *>>> Running: tf vc help*
> *>>> Checking for a Subversion repository...*
> *>>> Unable to execute "svn help": skipping SVN*
> *>>> Checking for a Git repository...*
> *>>> Running: git rev-parse --git-dir*
> *>>> Running: git config core.bare*
> *>>> Running: git rev-parse --show-toplevel*
> *>>> Running: git symbolic-ref -q HEAD*
> *Traceback (most recent call last):*
> *  File "C:\Program Files
> (x86)\RBTools\bin\..\Python27\Scripts\rbt-script.py", line 11, in *
> *load_entry_point('RBTools==1.0.3', 'console_scripts', 'rbt')()*
> *  File "C:\Program Files
> (x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\commands\main.py",
> line 120, in main*
> *command.run_from_argv([RB_MAIN, command_name] + args)*
> *  File "C:\Program Files
> (x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\commands\__init__.py",
> line 725, in run_from_argv*
> *exit_code = self.main(*args) or 0*
> *  File "C:\Program Files
> (x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\commands\setup_repo.py",
> line 105, in main*
> *repository_info, tool = self.initialize_scm_tool()*
> *  File "C:\Program Files
> (x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\commands\__init__.py",
> line 754, in initialize_scm_tool*
> *client_name=client_name)*
> *  File "C:\Program Files
> (x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\clients\__init__.py",
> line 803, in scan_usable_client*
> *repository_info = tool.get_repository_info()*
> *  File "C:\Program Files
> (x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\clients\git.py",
> line 284, in get_repository_info*
> *ignore_errors=True).strip()*
> *  File "C:\Program Files
> (x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\clients\git.py",
> line 1261, in _execute*
> *return execute(cmdline, cwd=self._git_toplevel, *args, **kwargs)*
> *  File "C:\Program Files
> (x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\utils\process.py",
> line 155, in execute*
> ***popen_encoding_args)*
> *  File "C:\Program Files (x86)\RBTools\Python27\lib\subprocess.py", line
> 394, in __init__*
> *errread, errwrite)*
> *  File "C:\Program Files (x86)\RBTools\Python27\lib\subprocess.py", line
> 644, in _execute_child*
> *startupinfo)*
> *WindowsError: [Error 267] The directory name is invalid*
>
> If I try post command, report looks like this:
>
> *d:\git_repository>rbt post --debug*
> *>>> RBTools 1.0.3*
> *>>> Python 2.7.17 (v2.7.17:c2f86d86e6, Oct 19 2019, 20:49:36) [MSC v.1500
> 32 bit (Intel)]*
> *>>> Running on Windows-10-10.0.17134*
> *>>> Home = C:\Users\z003fbrn\AppData\Roaming*
> *>>> Current directory = d:\Ruzek\LEIA\Emitter\sitrans-tdl-emitter*
> *>>> Command line: rbt post --debug*
> *>>> Running: tf vc help*
> *>>> Checking for a Subversion repository...*
> *>>> Unable to execute "svn help": skipping SVN*
> *>>> Checking for a Git repository...*
> *>>> Running: git rev-parse --git-dir*
> *>>> Running: git config core.bare*
> *>>> Running: git rev-parse --show-toplevel*
> *>>> Running: git symbolic-ref -q HEAD*
> *Traceback (most recent call last):*
> *  File "C:\Program Files
> (x86)\RBTools\bin\..\Python27\Scripts\rbt-script.py", line 11, in *
> *load_entry_point('RBTools==1.0.3', 'console_scripts', 'rbt')()*
> *  File "C:\Program Files
> (x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\commands\main.py",
> line 120, in main*
> *command.run_from_argv([RB_MAIN, command_name] + args)*
> *  File "C:\Program Files
> (x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\commands\__init__.py",
> line 725, in run_from_argv*
> *exit_code = self.main(*args) or 0*
> *  File "C:\Program Files
> (x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\commands\post.py",
> line 756, in main*
> *client_name=self.options.repository_type)*
> *  File "C:\Program Files
> (x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtool

Re: Reviewboard showing only 20 branches of gitlab repository

[korta...@email.cz]

Hi Christian,

Unfortunately I am still struggling.

The gitlab support directed me to check this: 
https://www.reviewboard.org/docs/manual/1.5/admin/management/repositories/#determining-repository-information
 
This sounded like exactly my problem, for I see the branches, but cannot 
access a single file. I then realized that is nonsense, because if that 
would be the problem, then it wouldn't work even for the public repository 
(I tested it myself, and really when I switch a repository to public, it 
magically starts to work).

But it gave me the idea to try to add the repository as "custom repository" 
and try to fill in the "Raw file URL mask" - I tried it and encountered 
another error :-(

Environment can only contain strings

I found by google, that this was a discussed error at around 2015, but no 
solution was presented. Is it some bug that returned? Can I do something 
with it?

I tried to explore some more in the Gitlab and Reviewboard settings - tried 
something called deploy token and deploy keys, but nothing seems to work.

Also I found I can add applications to my Gitlab account, but I need 
something called "Redirect URI" but I have no idea where to get it for 
Reviewboard... I tried to put there my reviewboard server address, but that 
don't work either.

What I found out is that when I try to create the review, the Gitlab do not 
even register any movement on my account. So I really believe the problem 
is somewhere in the API token and logging and recognizing the user. 
Couldn't a problem be, that we use two-factor authentication and a Siemens 
entitlement for logging into the Gitlab repository? The API token should be 
able to pierce that though, shouldn't it?

I am getting frustrated by this to be honest, for it seems we will have to 
try out some another tool, which is exactly what I wanted to avoid, for we 
already approved that Reviewboard is suitable for our SIL needs.

About the RBTools problem - Martin had some computer breakdown and cannot 
continue with the experiments at the moment. He will continue as soon as he 
is able.

Thanks for any further help, I am currently running out of ideas.

Dne pátek 22. května 2020 23:00:15 UTC+2 Christian Hammond napsal(a):
>
> Hi Martin,
>
> The error is coming from Git, it seems. Can you run this command from that 
> directory and see what it says:
>
> git symbolic-ref -q HEAD
>
> Christian
>
>
> On Fri, May 22, 2020 at 08:51 Martin Růžek  > wrote:
>
>> Hi,
>>
>> I'm that person trying to use it on real repository.
>> I hit this error even during setup-repo command. I passed --debug 
>> parameter and output looks like this:
>>
>> *D:\git_repository>rbt setup-repo --debug*
>> *>>> RBTools 1.0.3*
>> *>>> Python 2.7.17 (v2.7.17:c2f86d86e6, Oct 19 2019, 20:49:36) [MSC 
>> v.1500 32 bit (Intel)]*
>> *>>> Running on Windows-10-10.0.17134*
>> *>>> Home = C:\Users\z003fbrn\AppData\Roaming*
>> *>>> Current directory = d:\Ruzek\LEIA\Emitter\sitrans-tdl-emitter*
>> *>>> Command line: rbt setup-repo --debug*
>> *Enter the Review Board server URL: 
>> https://czprga99033srv.ad001.siemens.net:444/ 
>> *
>> *>>> Running: tf vc help*
>> *>>> Checking for a Subversion repository...*
>> *>>> Unable to execute "svn help": skipping SVN*
>> *>>> Checking for a Git repository...*
>> *>>> Running: git rev-parse --git-dir*
>> *>>> Running: git config core.bare*
>> *>>> Running: git rev-parse --show-toplevel*
>> *>>> Running: git symbolic-ref -q HEAD*
>> *Traceback (most recent call last):*
>> *  File "C:\Program Files 
>> (x86)\RBTools\bin\..\Python27\Scripts\rbt-script.py", line 11, in *
>> *load_entry_point('RBTools==1.0.3', 'console_scripts', 'rbt')()*
>> *  File "C:\Program Files 
>> (x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\commands\main.py",
>>  
>> line 120, in main*
>> *command.run_from_argv([RB_MAIN, command_name] + args)*
>> *  File "C:\Program Files 
>> (x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\commands\__init__.py",
>>  
>> line 725, in run_from_argv*
>> *exit_code = self.main(*args) or 0*
>> *  File "C:\Program Files 
>> (x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\commands\setup_repo.py",
>>  
>> line 105, in main*
>> *repository_info, tool = self.initialize_scm_tool()*
>> *  File "C:\Program Files 
>> (x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\commands\__init__.py",
>>  
>> line 754, in initialize_scm_tool*
>> *client_name=client_name)*
>> *  File "C:\Program Files 
>> (x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\clients\__init__.py",
>>  
>> line 803, in scan_usable_client*
>> *repository_info = tool.get_repository_info()*
>> *  File "C:\Program Files 
>> (x86)\RBTools\Python27\lib\site-packages\rbtools-1.0.3-py2.7.egg\rbtools\clients\git.py",
>>  
>> line 284, in get_repository_info*
>> *ignore_errors=True).strip()*
>> *  F

Re: Reviewboard showing only 20 branches of gitlab repository

[Christian Hammond]

There’s two things in this thread that I think are getting jumbled
together. There’s the RBTools issue, and the GitLab configuration. They’re
independent, and I think it’s best to focus on one per thread.

For GitLab, it sounds like there’s two issues:

1) The branch limit. This will be fixed in the next release. That release
is delayed as my primary computer is currently awaiting its position in a
queue at Apple for repairs, and I’m in lockdown, making this a bit more
difficult to deal with than normal...

2) Access control issues with that repository, which seems to be the more
urgent issue.

You mentioned the 1.5 docs, and tried solutions from it, but much has
changed since 1.5. Nothing from there will be helpful, and there’s no way
for a non-GitLab Git repository entry to talk to GitLab. You won’t want to
go down that path any further. It’s a hard requirement to use the GitLab
hosting type to talk to a GitLab repository.

It does still seem to me to be an issue with the accessing user not having
permissions to access commit info on the repository in question. What can
you tell me about that user?

Christian



On Thu, May 28, 2020 at 09:00 korta...@email.cz  wrote:

> Hi Christian,
>
> Unfortunately I am still struggling.
>
> The gitlab support directed me to check this:
> https://www.reviewboard.org/docs/manual/1.5/admin/management/repositories/#determining-repository-information
> This sounded like exactly my problem, for I see the branches, but cannot
> access a single file. I then realized that is nonsense, because if that
> would be the problem, then it wouldn't work even for the public repository
> (I tested it myself, and really when I switch a repository to public, it
> magically starts to work).
>
> But it gave me the idea to try to add the repository as "custom
> repository" and try to fill in the "Raw file URL mask" - I tried it and
> encountered another error :-(
>
> Environment can only contain strings
>
> I found by google, that this was a discussed error at around 2015, but no
> solution was presented. Is it some bug that returned? Can I do something
> with it?
>
> I tried to explore some more in the Gitlab and Reviewboard settings -
> tried something called deploy token and deploy keys, but nothing seems to
> work.
>
> Also I found I can add applications to my Gitlab account, but I need
> something called "Redirect URI" but I have no idea where to get it for
> Reviewboard... I tried to put there my reviewboard server address, but that
> don't work either.
>
> What I found out is that when I try to create the review, the Gitlab do
> not even register any movement on my account. So I really believe the
> problem is somewhere in the API token and logging and recognizing the user.
> Couldn't a problem be, that we use two-factor authentication and a Siemens
> entitlement for logging into the Gitlab repository? The API token should be
> able to pierce that though, shouldn't it?
>
> I am getting frustrated by this to be honest, for it seems we will have to
> try out some another tool, which is exactly what I wanted to avoid, for we
> already approved that Reviewboard is suitable for our SIL needs.
>
> About the RBTools problem - Martin had some computer breakdown and cannot
> continue with the experiments at the moment. He will continue as soon as he
> is able.
>
> Thanks for any further help, I am currently running out of ideas.
>
> Dne pátek 22. května 2020 23:00:15 UTC+2 Christian Hammond napsal(a):
>>
>> Hi Martin,
>>
>> The error is coming from Git, it seems. Can you run this command from
>> that directory and see what it says:
>>
>> git symbolic-ref -q HEAD
>>
>> Christian
>>
>>
>> On Fri, May 22, 2020 at 08:51 Martin Růžek  wrote:
>>
> Hi,
>>>
>>> I'm that person trying to use it on real repository.
>>> I hit this error even during setup-repo command. I passed --debug
>>> parameter and output looks like this:
>>>
>>> *D:\git_repository>rbt setup-repo --debug*
>>> *>>> RBTools 1.0.3*
>>> *>>> Python 2.7.17 (v2.7.17:c2f86d86e6, Oct 19 2019, 20:49:36) [MSC
>>> v.1500 32 bit (Intel)]*
>>> *>>> Running on Windows-10-10.0.17134*
>>> *>>> Home = C:\Users\z003fbrn\AppData\Roaming*
>>> *>>> Current directory = d:\Ruzek\LEIA\Emitter\sitrans-tdl-emitter*
>>> *>>> Command line: rbt setup-repo --debug*
>>> *Enter the Review Board server URL:
>>> https://czprga99033srv.ad001.siemens.net:444/
>>> *
>>> *>>> Running: tf vc help*
>>> *>>> Checking for a Subversion repository...*
>>> *>>> Unable to execute "svn help": skipping SVN*
>>> *>>> Checking for a Git repository...*
>>> *>>> Running: git rev-parse --git-dir*
>>> *>>> Running: git config core.bare*
>>> *>>> Running: git rev-parse --show-toplevel*
>>> *>>> Running: git symbolic-ref -q HEAD*
>>> *Traceback (most recent call last):*
>>> *  File "C:\Program Files
>>> (x86)\RBTools\bin\..\Python27\Scripts\rbt-script.py", line 11, in *
>>> *load_entry_point('RBTools==1.0.3', 'console_scripts', 'rbt'

Re: Reviewboard showing only 20 branches of gitlab repository

[korta...@email.cz]

Yes, the RBTools seems completely different problem (and we might solve it 
yet, we found what we did wrong, need some more testing). We will open 
different thread if needed.

The branch limit is also not an issue anymore, we changed the structure, so 
now we can reach the branches we need, and as you said - will be solved in 
next release.

But the problem with the access is still an isssue. I have tried with 
several users, included the owner of the repository. Every one has the same 
issue.
Every user I tested is able to make a clone of the repository, so they 
definetly should have access. 

If I check in GitLab, it does not even register usage of the API token.

One of my colleagues said he had also problem with access to the repository 
from another tool (Jenkins). He found out the problem is with the HTTPS 
access. He managed to successfully access the repository with SSH. This is 
why I wanted to try the general Git repository entry, because there is 
possibilitiy to set an SSH entry there.

I am also communicating with our GitLab support, but they are not much 
helpfull yet... I have some new name to contact, so hopefully he will have 
some insight.


Thank you for still keeping this thread active, I already spent too much 
time on this and the management is starting to have questions, so if I do 
not solve it soon, I will have to go for another review tool...



Dne pondělí 8. června 2020 0:03:44 UTC+2 Christian Hammond napsal(a):
>
> There’s two things in this thread that I think are getting jumbled 
> together. There’s the RBTools issue, and the GitLab configuration. They’re 
> independent, and I think it’s best to focus on one per thread.
>
> For GitLab, it sounds like there’s two issues:
>
> 1) The branch limit. This will be fixed in the next release. That release 
> is delayed as my primary computer is currently awaiting its position in a 
> queue at Apple for repairs, and I’m in lockdown, making this a bit more 
> difficult to deal with than normal...
>
> 2) Access control issues with that repository, which seems to be the more 
> urgent issue.
>
> You mentioned the 1.5 docs, and tried solutions from it, but much has 
> changed since 1.5. Nothing from there will be helpful, and there’s no way 
> for a non-GitLab Git repository entry to talk to GitLab. You won’t want to 
> go down that path any further. It’s a hard requirement to use the GitLab 
> hosting type to talk to a GitLab repository.
>
> It does still seem to me to be an issue with the accessing user not having 
> permissions to access commit info on the repository in question. What can 
> you tell me about that user?
>
> Christian
>
>
>
> On Thu, May 28, 2020 at 09:00 kort...@email.cz  <
> kort...@email.cz > wrote:
>
>> Hi Christian,
>>
>> Unfortunately I am still struggling.
>>
>> The gitlab support directed me to check this: 
>> https://www.reviewboard.org/docs/manual/1.5/admin/management/repositories/#determining-repository-information
>>  
>> This sounded like exactly my problem, for I see the branches, but cannot 
>> access a single file. I then realized that is nonsense, because if that 
>> would be the problem, then it wouldn't work even for the public repository 
>> (I tested it myself, and really when I switch a repository to public, it 
>> magically starts to work).
>>
>> But it gave me the idea to try to add the repository as "custom 
>> repository" and try to fill in the "Raw file URL mask" - I tried it and 
>> encountered another error :-(
>>
>> Environment can only contain strings
>>
>> I found by google, that this was a discussed error at around 2015, but no 
>> solution was presented. Is it some bug that returned? Can I do something 
>> with it?
>>
>> I tried to explore some more in the Gitlab and Reviewboard settings - 
>> tried something called deploy token and deploy keys, but nothing seems to 
>> work.
>>
>> Also I found I can add applications to my Gitlab account, but I need 
>> something called "Redirect URI" but I have no idea where to get it for 
>> Reviewboard... I tried to put there my reviewboard server address, but that 
>> don't work either.
>>
>> What I found out is that when I try to create the review, the Gitlab do 
>> not even register any movement on my account. So I really believe the 
>> problem is somewhere in the API token and logging and recognizing the user. 
>> Couldn't a problem be, that we use two-factor authentication and a Siemens 
>> entitlement for logging into the Gitlab repository? The API token should be 
>> able to pierce that though, shouldn't it?
>>
>> I am getting frustrated by this to be honest, for it seems we will have 
>> to try out some another tool, which is exactly what I wanted to avoid, for 
>> we already approved that Reviewboard is suitable for our SIL needs.
>>
>> About the RBTools problem - Martin had some computer breakdown and cannot 
>> continue with the experiments at the moment. He will continue as soon as he 
>> is able.
>>
>> Thanks for any further help, I am

Re: Reviewboard showing only 20 branches of gitlab repository

[korta...@email.cz]

I just found:
"cloning per https is blocked from the internet, if you want to clone from 
internet you need to use ssh"
That seems like the real problem...
sooo... How can I persuade Reviewboard to communicate with GitLab over SSH?

Dne úterý 16. června 2020 15:05:43 UTC+2 kort...@email.cz napsal(a):
>
> Yes, the RBTools seems completely different problem (and we might solve it 
> yet, we found what we did wrong, need some more testing). We will open 
> different thread if needed.
>
> The branch limit is also not an issue anymore, we changed the structure, 
> so now we can reach the branches we need, and as you said - will be solved 
> in next release.
>
> But the problem with the access is still an isssue. I have tried with 
> several users, included the owner of the repository. Every one has the same 
> issue.
> Every user I tested is able to make a clone of the repository, so they 
> definetly should have access. 
>
> If I check in GitLab, it does not even register usage of the API token.
>
> One of my colleagues said he had also problem with access to the 
> repository from another tool (Jenkins). He found out the problem is with 
> the HTTPS access. He managed to successfully access the repository with 
> SSH. This is why I wanted to try the general Git repository entry, because 
> there is possibilitiy to set an SSH entry there.
>
> I am also communicating with our GitLab support, but they are not much 
> helpfull yet... I have some new name to contact, so hopefully he will have 
> some insight.
>
>
> Thank you for still keeping this thread active, I already spent too much 
> time on this and the management is starting to have questions, so if I do 
> not solve it soon, I will have to go for another review tool...
>
>
>
> Dne pondělí 8. června 2020 0:03:44 UTC+2 Christian Hammond napsal(a):
>>
>> There’s two things in this thread that I think are getting jumbled 
>> together. There’s the RBTools issue, and the GitLab configuration. They’re 
>> independent, and I think it’s best to focus on one per thread.
>>
>> For GitLab, it sounds like there’s two issues:
>>
>> 1) The branch limit. This will be fixed in the next release. That release 
>> is delayed as my primary computer is currently awaiting its position in a 
>> queue at Apple for repairs, and I’m in lockdown, making this a bit more 
>> difficult to deal with than normal...
>>
>> 2) Access control issues with that repository, which seems to be the more 
>> urgent issue.
>>
>> You mentioned the 1.5 docs, and tried solutions from it, but much has 
>> changed since 1.5. Nothing from there will be helpful, and there’s no way 
>> for a non-GitLab Git repository entry to talk to GitLab. You won’t want to 
>> go down that path any further. It’s a hard requirement to use the GitLab 
>> hosting type to talk to a GitLab repository.
>>
>> It does still seem to me to be an issue with the accessing user not 
>> having permissions to access commit info on the repository in question. 
>> What can you tell me about that user?
>>
>> Christian
>>
>>
>>
>> On Thu, May 28, 2020 at 09:00 kort...@email.cz  wrote:
>>
>>> Hi Christian,
>>>
>>> Unfortunately I am still struggling.
>>>
>>> The gitlab support directed me to check this: 
>>> https://www.reviewboard.org/docs/manual/1.5/admin/management/repositories/#determining-repository-information
>>>  
>>> This sounded like exactly my problem, for I see the branches, but cannot 
>>> access a single file. I then realized that is nonsense, because if that 
>>> would be the problem, then it wouldn't work even for the public repository 
>>> (I tested it myself, and really when I switch a repository to public, it 
>>> magically starts to work).
>>>
>>> But it gave me the idea to try to add the repository as "custom 
>>> repository" and try to fill in the "Raw file URL mask" - I tried it and 
>>> encountered another error :-(
>>>
>>> Environment can only contain strings
>>>
>>> I found by google, that this was a discussed error at around 2015, but 
>>> no solution was presented. Is it some bug that returned? Can I do something 
>>> with it?
>>>
>>> I tried to explore some more in the Gitlab and Reviewboard settings - 
>>> tried something called deploy token and deploy keys, but nothing seems to 
>>> work.
>>>
>>> Also I found I can add applications to my Gitlab account, but I need 
>>> something called "Redirect URI" but I have no idea where to get it for 
>>> Reviewboard... I tried to put there my reviewboard server address, but that 
>>> don't work either.
>>>
>>> What I found out is that when I try to create the review, the Gitlab do 
>>> not even register any movement on my account. So I really believe the 
>>> problem is somewhere in the API token and logging and recognizing the user. 
>>> Couldn't a problem be, that we use two-factor authentication and a Siemens 
>>> entitlement for logging into the Gitlab repository? The API token should be 
>>> able to pierce that though, shouldn't it?
>>>
>>> I am getting frustrated b

Re: Reviewboard showing only 20 branches of gitlab repository

[Christian Hammond]

We don't talk directly to the repository, or clone it, so that error
probably isn't related to us?

We communicate solely with the GitLab API, and we're using the standard
GitLab API calls. We know that the authentication is working via those
calls, because you'd get an error much earlier. If it's failing to fetch
the commits, that's something that other tools are going to hit as well.
It's GitLab blocking something when accessing that URL.

Perhaps you can try making equivalent calls from the command line. We're
calling the /api/v4/projects//repository/commits/ API, with
a "PRIVATE-TOKEN: " header. It appears Review Board is getting a 404
when that happens. An API call made by, say, `curl`, or Postman
 should see the same behavior with the same
credentials.

The private token we use is the one provided when authorizing against the
repository in the repository form (click Edit Credentials to change this
token).

Christian

On Tue, Jun 16, 2020 at 6:19 AM korta...@email.cz  wrote:

> I just found:
> "cloning per https is blocked from the internet, if you want to clone
> from internet you need to use ssh"
> That seems like the real problem...
> sooo... How can I persuade Reviewboard to communicate with GitLab over SSH?
>
> Dne úterý 16. června 2020 15:05:43 UTC+2 kort...@email.cz napsal(a):
>>
>> Yes, the RBTools seems completely different problem (and we might solve
>> it yet, we found what we did wrong, need some more testing). We will open
>> different thread if needed.
>>
>> The branch limit is also not an issue anymore, we changed the structure,
>> so now we can reach the branches we need, and as you said - will be solved
>> in next release.
>>
>> But the problem with the access is still an isssue. I have tried with
>> several users, included the owner of the repository. Every one has the same
>> issue.
>> Every user I tested is able to make a clone of the repository, so they
>> definetly should have access.
>>
>> If I check in GitLab, it does not even register usage of the API token.
>>
>> One of my colleagues said he had also problem with access to the
>> repository from another tool (Jenkins). He found out the problem is with
>> the HTTPS access. He managed to successfully access the repository with
>> SSH. This is why I wanted to try the general Git repository entry, because
>> there is possibilitiy to set an SSH entry there.
>>
>> I am also communicating with our GitLab support, but they are not much
>> helpfull yet... I have some new name to contact, so hopefully he will have
>> some insight.
>>
>>
>> Thank you for still keeping this thread active, I already spent too much
>> time on this and the management is starting to have questions, so if I do
>> not solve it soon, I will have to go for another review tool...
>>
>>
>>
>> Dne pondělí 8. června 2020 0:03:44 UTC+2 Christian Hammond napsal(a):
>>>
>>> There’s two things in this thread that I think are getting jumbled
>>> together. There’s the RBTools issue, and the GitLab configuration. They’re
>>> independent, and I think it’s best to focus on one per thread.
>>>
>>> For GitLab, it sounds like there’s two issues:
>>>
>>> 1) The branch limit. This will be fixed in the next release. That
>>> release is delayed as my primary computer is currently awaiting its
>>> position in a queue at Apple for repairs, and I’m in lockdown, making this
>>> a bit more difficult to deal with than normal...
>>>
>>> 2) Access control issues with that repository, which seems to be the
>>> more urgent issue.
>>>
>>> You mentioned the 1.5 docs, and tried solutions from it, but much has
>>> changed since 1.5. Nothing from there will be helpful, and there’s no way
>>> for a non-GitLab Git repository entry to talk to GitLab. You won’t want to
>>> go down that path any further. It’s a hard requirement to use the GitLab
>>> hosting type to talk to a GitLab repository.
>>>
>>> It does still seem to me to be an issue with the accessing user not
>>> having permissions to access commit info on the repository in question.
>>> What can you tell me about that user?
>>>
>>> Christian
>>>
>>>
>>>
>>> On Thu, May 28, 2020 at 09:00 kort...@email.cz  wrote:
>>>
 Hi Christian,

 Unfortunately I am still struggling.

 The gitlab support directed me to check this:
 https://www.reviewboard.org/docs/manual/1.5/admin/management/repositories/#determining-repository-information
 This sounded like exactly my problem, for I see the branches, but
 cannot access a single file. I then realized that is nonsense, because if
 that would be the problem, then it wouldn't work even for the public
 repository (I tested it myself, and really when I switch a repository to
 public, it magically starts to work).

 But it gave me the idea to try to add the repository as "custom
 repository" and try to fill in the "Raw file URL mask" - I tried it and
 encountered another error :-(

 Environment can only contain strin

Re: Reviewboard showing only 20 branches of gitlab repository

[korta...@email.cz]

I finally got to someone competent on the GitLab side, so maybe we will get 
somewhere... His first idea is that the credentials management is somehow 
incompatible between review board and our GitLab. He is investigating now.

Meanwhile we succeeded in using the RBTools to some extent. We don't have a 
review yet, but it seems the colleague was able to do a fetch operation 
successfully:
"

/r/41/diff/1/fragment/20/ - root - Fetching file 
'Project/Emitter_Unit/source/application/Communication/TimeSynchronization/CServerUDP.cpp'
 rf26817a5f5799a477b0d858b135781470b41 (base commit ID 
9ba489121bb89c93900020b3838cb50f232df3ed) from GIT Leia - emitter took 0.343000 
seconds
"
The error before was caused by him using wrong Review Board login user name :-) 
The error message was so vague though, that we found out by accident just 
recently. We will try to work with it further, but we would still rather have 
the browser form working...



Dne středa 17. června 2020 4:33:24 UTC+2 Christian Hammond napsal(a):
>
> We don't talk directly to the repository, or clone it, so that error 
> probably isn't related to us?
>
> We communicate solely with the GitLab API, and we're using the standard 
> GitLab API calls. We know that the authentication is working via those 
> calls, because you'd get an error much earlier. If it's failing to fetch 
> the commits, that's something that other tools are going to hit as well. 
> It's GitLab blocking something when accessing that URL.
>
> Perhaps you can try making equivalent calls from the command line. We're 
> calling the /api/v4/projects//repository/commits/ API, with 
> a "PRIVATE-TOKEN: " header. It appears Review Board is getting a 404 
> when that happens. An API call made by, say, `curl`, or Postman 
>  should see the same behavior with the same 
> credentials.
>
> The private token we use is the one provided when authorizing against the 
> repository in the repository form (click Edit Credentials to change this 
> token).
>
> Christian
>
> On Tue, Jun 16, 2020 at 6:19 AM kort...@email.cz  <
> kort...@email.cz > wrote:
>
>> I just found:
>> "cloning per https is blocked from the internet, if you want to clone 
>> from internet you need to use ssh"
>> That seems like the real problem...
>> sooo... How can I persuade Reviewboard to communicate with GitLab over 
>> SSH?
>>
>> Dne úterý 16. června 2020 15:05:43 UTC+2 kort...@email.cz napsal(a):
>>>
>>> Yes, the RBTools seems completely different problem (and we might solve 
>>> it yet, we found what we did wrong, need some more testing). We will open 
>>> different thread if needed.
>>>
>>> The branch limit is also not an issue anymore, we changed the structure, 
>>> so now we can reach the branches we need, and as you said - will be solved 
>>> in next release.
>>>
>>> But the problem with the access is still an isssue. I have tried with 
>>> several users, included the owner of the repository. Every one has the same 
>>> issue.
>>> Every user I tested is able to make a clone of the repository, so they 
>>> definetly should have access. 
>>>
>>> If I check in GitLab, it does not even register usage of the API token.
>>>
>>> One of my colleagues said he had also problem with access to the 
>>> repository from another tool (Jenkins). He found out the problem is with 
>>> the HTTPS access. He managed to successfully access the repository with 
>>> SSH. This is why I wanted to try the general Git repository entry, because 
>>> there is possibilitiy to set an SSH entry there.
>>>
>>> I am also communicating with our GitLab support, but they are not much 
>>> helpfull yet... I have some new name to contact, so hopefully he will have 
>>> some insight.
>>>
>>>
>>> Thank you for still keeping this thread active, I already spent too much 
>>> time on this and the management is starting to have questions, so if I do 
>>> not solve it soon, I will have to go for another review tool...
>>>
>>>
>>>
>>> Dne pondělí 8. června 2020 0:03:44 UTC+2 Christian Hammond napsal(a):

 There’s two things in this thread that I think are getting jumbled 
 together. There’s the RBTools issue, and the GitLab configuration. They’re 
 independent, and I think it’s best to focus on one per thread.

 For GitLab, it sounds like there’s two issues:

 1) The branch limit. This will be fixed in the next release. That 
 release is delayed as my primary computer is currently awaiting its 
 position in a queue at Apple for repairs, and I’m in lockdown, making this 
 a bit more difficult to deal with than normal...

 2) Access control issues with that repository, which seems to be the 
 more urgent issue.

 You mentioned the 1.5 docs, and tried solutions from it, but much has 
 changed since 1.5. Nothing from there will be helpful, and there’s no way 
 for a non-GitLab Git repository entry to talk to GitLab. You won’t want to 
 go down that path any further

Re: Reviewboard showing only 20 branches of gitlab repository

[korta...@email.cz]

Is it possible to see in Review Board dump of all executed API commands?

Dne středa 17. června 2020 12:45:13 UTC+2 kort...@email.cz napsal(a):
>
> I finally got to someone competent on the GitLab side, so maybe we will 
> get somewhere... His first idea is that the credentials management is 
> somehow incompatible between review board and our GitLab. He is 
> investigating now.
>
> Meanwhile we succeeded in using the RBTools to some extent. We don't have 
> a review yet, but it seems the colleague was able to do a fetch operation 
> successfully:
> "
>
> /r/41/diff/1/fragment/20/ - root - Fetching file 
> 'Project/Emitter_Unit/source/application/Communication/TimeSynchronization/CServerUDP.cpp'
>  rf26817a5f5799a477b0d858b135781470b41 (base commit ID 
> 9ba489121bb89c93900020b3838cb50f232df3ed) from GIT Leia - emitter took 
> 0.343000 seconds
> "
> The error before was caused by him using wrong Review Board login user name 
> :-) The error message was so vague though, that we found out by accident just 
> recently. We will try to work with it further, but we would still rather have 
> the browser form working...
>
>
>
> Dne středa 17. června 2020 4:33:24 UTC+2 Christian Hammond napsal(a):
>>
>> We don't talk directly to the repository, or clone it, so that error 
>> probably isn't related to us?
>>
>> We communicate solely with the GitLab API, and we're using the standard 
>> GitLab API calls. We know that the authentication is working via those 
>> calls, because you'd get an error much earlier. If it's failing to fetch 
>> the commits, that's something that other tools are going to hit as well. 
>> It's GitLab blocking something when accessing that URL.
>>
>> Perhaps you can try making equivalent calls from the command line. We're 
>> calling the /api/v4/projects//repository/commits/ API, with 
>> a "PRIVATE-TOKEN: " header. It appears Review Board is getting a 404 
>> when that happens. An API call made by, say, `curl`, or Postman 
>>  should see the same behavior with the same 
>> credentials.
>>
>> The private token we use is the one provided when authorizing against the 
>> repository in the repository form (click Edit Credentials to change this 
>> token).
>>
>> Christian
>>
>> On Tue, Jun 16, 2020 at 6:19 AM kort...@email.cz  
>> wrote:
>>
>>> I just found:
>>> "cloning per https is blocked from the internet, if you want to clone 
>>> from internet you need to use ssh"
>>> That seems like the real problem...
>>> sooo... How can I persuade Reviewboard to communicate with GitLab over 
>>> SSH?
>>>
>>> Dne úterý 16. června 2020 15:05:43 UTC+2 kort...@email.cz napsal(a):

 Yes, the RBTools seems completely different problem (and we might solve 
 it yet, we found what we did wrong, need some more testing). We will open 
 different thread if needed.

 The branch limit is also not an issue anymore, we changed the 
 structure, so now we can reach the branches we need, and as you said - 
 will 
 be solved in next release.

 But the problem with the access is still an isssue. I have tried with 
 several users, included the owner of the repository. Every one has the 
 same 
 issue.
 Every user I tested is able to make a clone of the repository, so they 
 definetly should have access. 

 If I check in GitLab, it does not even register usage of the API token.

 One of my colleagues said he had also problem with access to the 
 repository from another tool (Jenkins). He found out the problem is with 
 the HTTPS access. He managed to successfully access the repository with 
 SSH. This is why I wanted to try the general Git repository entry, because 
 there is possibilitiy to set an SSH entry there.

 I am also communicating with our GitLab support, but they are not much 
 helpfull yet... I have some new name to contact, so hopefully he will have 
 some insight.


 Thank you for still keeping this thread active, I already spent too 
 much time on this and the management is starting to have questions, so if 
 I 
 do not solve it soon, I will have to go for another review tool...



 Dne pondělí 8. června 2020 0:03:44 UTC+2 Christian Hammond napsal(a):
>
> There’s two things in this thread that I think are getting jumbled 
> together. There’s the RBTools issue, and the GitLab configuration. 
> They’re 
> independent, and I think it’s best to focus on one per thread.
>
> For GitLab, it sounds like there’s two issues:
>
> 1) The branch limit. This will be fixed in the next release. That 
> release is delayed as my primary computer is currently awaiting its 
> position in a queue at Apple for repairs, and I’m in lockdown, making 
> this 
> a bit more difficult to deal with than normal...
>
> 2) Access control issues with that repository, which seems to be the 
> more urgen

Re: Reviewboard showing only 20 branches of gitlab repository

[Christian Hammond]

All the GitLab API commands? No, we don't log that I'm afraid. What do you
want to see out of it?

Christian

On Wed, Jun 17, 2020 at 3:49 AM korta...@email.cz  wrote:

> Is it possible to see in Review Board dump of all executed API commands?
>
> Dne středa 17. června 2020 12:45:13 UTC+2 kort...@email.cz napsal(a):
>>
>> I finally got to someone competent on the GitLab side, so maybe we will
>> get somewhere... His first idea is that the credentials management is
>> somehow incompatible between review board and our GitLab. He is
>> investigating now.
>>
>> Meanwhile we succeeded in using the RBTools to some extent. We don't have
>> a review yet, but it seems the colleague was able to do a fetch operation
>> successfully:
>> "
>>
>> /r/41/diff/1/fragment/20/ - root - Fetching file 
>> 'Project/Emitter_Unit/source/application/Communication/TimeSynchronization/CServerUDP.cpp'
>>  rf26817a5f5799a477b0d858b135781470b41 (base commit ID 
>> 9ba489121bb89c93900020b3838cb50f232df3ed) from GIT Leia - emitter took 
>> 0.343000 seconds
>> "
>> The error before was caused by him using wrong Review Board login user name 
>> :-) The error message was so vague though, that we found out by accident 
>> just recently. We will try to work with it further, but we would still 
>> rather have the browser form working...
>>
>>
>>
>> Dne středa 17. června 2020 4:33:24 UTC+2 Christian Hammond napsal(a):
>>>
>>> We don't talk directly to the repository, or clone it, so that error
>>> probably isn't related to us?
>>>
>>> We communicate solely with the GitLab API, and we're using the standard
>>> GitLab API calls. We know that the authentication is working via those
>>> calls, because you'd get an error much earlier. If it's failing to fetch
>>> the commits, that's something that other tools are going to hit as well.
>>> It's GitLab blocking something when accessing that URL.
>>>
>>> Perhaps you can try making equivalent calls from the command line. We're
>>> calling the /api/v4/projects//repository/commits/ API, with
>>> a "PRIVATE-TOKEN: " header. It appears Review Board is getting a 404
>>> when that happens. An API call made by, say, `curl`, or Postman
>>>  should see the same behavior with the same
>>> credentials.
>>>
>>> The private token we use is the one provided when authorizing against
>>> the repository in the repository form (click Edit Credentials to change
>>> this token).
>>>
>>> Christian
>>>
>>> On Tue, Jun 16, 2020 at 6:19 AM kort...@email.cz 
>>> wrote:
>>>
 I just found:
 "cloning per https is blocked from the internet, if you want to clone
 from internet you need to use ssh"
 That seems like the real problem...
 sooo... How can I persuade Reviewboard to communicate with GitLab over
 SSH?

 Dne úterý 16. června 2020 15:05:43 UTC+2 kort...@email.cz napsal(a):
>
> Yes, the RBTools seems completely different problem (and we might
> solve it yet, we found what we did wrong, need some more testing). We will
> open different thread if needed.
>
> The branch limit is also not an issue anymore, we changed the
> structure, so now we can reach the branches we need, and as you said - 
> will
> be solved in next release.
>
> But the problem with the access is still an isssue. I have tried with
> several users, included the owner of the repository. Every one has the 
> same
> issue.
> Every user I tested is able to make a clone of the repository, so they
> definetly should have access.
>
> If I check in GitLab, it does not even register usage of the API token.
>
> One of my colleagues said he had also problem with access to the
> repository from another tool (Jenkins). He found out the problem is with
> the HTTPS access. He managed to successfully access the repository with
> SSH. This is why I wanted to try the general Git repository entry, because
> there is possibilitiy to set an SSH entry there.
>
> I am also communicating with our GitLab support, but they are not much
> helpfull yet... I have some new name to contact, so hopefully he will have
> some insight.
>
>
> Thank you for still keeping this thread active, I already spent too
> much time on this and the management is starting to have questions, so if 
> I
> do not solve it soon, I will have to go for another review tool...
>
>
>
> Dne pondělí 8. června 2020 0:03:44 UTC+2 Christian Hammond napsal(a):
>>
>> There’s two things in this thread that I think are getting jumbled
>> together. There’s the RBTools issue, and the GitLab configuration. 
>> They’re
>> independent, and I think it’s best to focus on one per thread.
>>
>> For GitLab, it sounds like there’s two issues:
>>
>> 1) The branch limit. This will be fixed in the next release. That
>> release is delayed as my primary computer is currently awaiting its
>

Re: Reviewboard showing only 20 branches of gitlab repository

[korta...@email.cz]

The GitLab support would like to see which commands are sent from your 
side, so they can identify what is wrong.

Dne sobota 20. června 2020 5:13:40 UTC+2 Christian Hammond napsal(a):
>
> All the GitLab API commands? No, we don't log that I'm afraid. What do you 
> want to see out of it?
>
> Christian
>
> On Wed, Jun 17, 2020 at 3:49 AM kort...@email.cz  <
> kort...@email.cz > wrote:
>
>> Is it possible to see in Review Board dump of all executed API commands?
>>
>> Dne středa 17. června 2020 12:45:13 UTC+2 kort...@email.cz napsal(a):
>>>
>>> I finally got to someone competent on the GitLab side, so maybe we will 
>>> get somewhere... His first idea is that the credentials management is 
>>> somehow incompatible between review board and our GitLab. He is 
>>> investigating now.
>>>
>>> Meanwhile we succeeded in using the RBTools to some extent. We don't 
>>> have a review yet, but it seems the colleague was able to do a fetch 
>>> operation successfully:
>>> "
>>>
>>> /r/41/diff/1/fragment/20/ - root - Fetching file 
>>> 'Project/Emitter_Unit/source/application/Communication/TimeSynchronization/CServerUDP.cpp'
>>>  rf26817a5f5799a477b0d858b135781470b41 (base commit ID 
>>> 9ba489121bb89c93900020b3838cb50f232df3ed) from GIT Leia - emitter took 
>>> 0.343000 seconds
>>> "
>>> The error before was caused by him using wrong Review Board login user name 
>>> :-) The error message was so vague though, that we found out by accident 
>>> just recently. We will try to work with it further, but we would still 
>>> rather have the browser form working...
>>>
>>>
>>>
>>> Dne středa 17. června 2020 4:33:24 UTC+2 Christian Hammond napsal(a):

 We don't talk directly to the repository, or clone it, so that error 
 probably isn't related to us?

 We communicate solely with the GitLab API, and we're using the standard 
 GitLab API calls. We know that the authentication is working via those 
 calls, because you'd get an error much earlier. If it's failing to fetch 
 the commits, that's something that other tools are going to hit as well. 
 It's GitLab blocking something when accessing that URL.

 Perhaps you can try making equivalent calls from the command line. 
 We're calling the /api/v4/projects//repository/commits/ 
 API, 
 with a "PRIVATE-TOKEN: " header. It appears Review Board is getting a 
 404 when that happens. An API call made by, say, `curl`, or Postman 
  should see the same behavior with the same 
 credentials.

 The private token we use is the one provided when authorizing against 
 the repository in the repository form (click Edit Credentials to change 
 this token).

 Christian

 On Tue, Jun 16, 2020 at 6:19 AM kort...@email.cz  
 wrote:

> I just found:
> "cloning per https is blocked from the internet, if you want to clone 
> from internet you need to use ssh"
> That seems like the real problem...
> sooo... How can I persuade Reviewboard to communicate with GitLab over 
> SSH?
>
> Dne úterý 16. června 2020 15:05:43 UTC+2 kort...@email.cz napsal(a):
>>
>> Yes, the RBTools seems completely different problem (and we might 
>> solve it yet, we found what we did wrong, need some more testing). We 
>> will 
>> open different thread if needed.
>>
>> The branch limit is also not an issue anymore, we changed the 
>> structure, so now we can reach the branches we need, and as you said - 
>> will 
>> be solved in next release.
>>
>> But the problem with the access is still an isssue. I have tried with 
>> several users, included the owner of the repository. Every one has the 
>> same 
>> issue.
>> Every user I tested is able to make a clone of the repository, so 
>> they definetly should have access. 
>>
>> If I check in GitLab, it does not even register usage of the API 
>> token.
>>
>> One of my colleagues said he had also problem with access to the 
>> repository from another tool (Jenkins). He found out the problem is with 
>> the HTTPS access. He managed to successfully access the repository with 
>> SSH. This is why I wanted to try the general Git repository entry, 
>> because 
>> there is possibilitiy to set an SSH entry there.
>>
>> I am also communicating with our GitLab support, but they are not 
>> much helpfull yet... I have some new name to contact, so hopefully he 
>> will 
>> have some insight.
>>
>>
>> Thank you for still keeping this thread active, I already spent too 
>> much time on this and the management is starting to have questions, so 
>> if I 
>> do not solve it soon, I will have to go for another review tool...
>>
>>
>>
>> Dne pondělí 8. června 2020 0:03:44 UTC+2 Christian Hammond napsal(a):
>>>
>>> There’s two things in this thread that I think 

Re: Reviewboard showing only 20 branches of gitlab repository

[Christian Hammond]

Authorization is performed by setting a PRIVATE-TOKEN:  header
with the token you provide for the account (which must have all necessary
permissions for the API).

When listing the commits, we send:

GET /api/v4/repository/commits?per_page=21&ref_name=master

(Replace "master" with whatever branch you've selected.)

When fetching an individual commit (after clicking a commit to post), we
may or may not send the following, depending on prior cached information:

GET /api/v4/repository/commits/

We then fetch the repository information, based on your configuration:

GET /api/v4/projects/

(The repository ID is cached permanently in your Review Board repository
entry's extra_data field under "gitlab_project_id" — if that's incorrect
for any reason, you'll hit issues. If that's missing from extra_data, it
will be refetched/cached based on the configured repository owner and name.)

>From that payload, we pull out the "path_with_namespace" parameter and then
perform:

GET /commit/.diff?private_token=


It's this call that's failing. I noticed we're using ?private_token= query
parameter here instead of the HTTP header. GitLab API docs claim this is
still valid for the API, but maybe it's not working here? We have other
GitLab customers who are using Review Board, but most people use RBTools,
which doesn't use this request. So there could be something there.

Or the auth token isn't able to access this resource. I should note we've
had issues in the past where a previously-accessible resource has become
unavailable. Perhaps that's happened.

Now, when we wrote this support, GitLab did not have an API available to
access the raw diff contents, so we had to go this route. I don't think
this is the right move anymore, and an API has since been added. We'll work
to move onto the new diff API. Perhaps this will solve the problem.

Christian


On Mon, Jun 22, 2020 at 2:12 AM korta...@email.cz  wrote:

> The GitLab support would like to see which commands are sent from your
> side, so they can identify what is wrong.
>
> Dne sobota 20. června 2020 5:13:40 UTC+2 Christian Hammond napsal(a):
>>
>> All the GitLab API commands? No, we don't log that I'm afraid. What do
>> you want to see out of it?
>>
>> Christian
>>
>> On Wed, Jun 17, 2020 at 3:49 AM kort...@email.cz 
>> wrote:
>>
>>> Is it possible to see in Review Board dump of all executed API commands?
>>>
>>> Dne středa 17. června 2020 12:45:13 UTC+2 kort...@email.cz napsal(a):

 I finally got to someone competent on the GitLab side, so maybe we will
 get somewhere... His first idea is that the credentials management is
 somehow incompatible between review board and our GitLab. He is
 investigating now.

 Meanwhile we succeeded in using the RBTools to some extent. We don't
 have a review yet, but it seems the colleague was able to do a fetch
 operation successfully:
 "

 /r/41/diff/1/fragment/20/ - root - Fetching file 
 'Project/Emitter_Unit/source/application/Communication/TimeSynchronization/CServerUDP.cpp'
  rf26817a5f5799a477b0d858b135781470b41 (base commit ID 
 9ba489121bb89c93900020b3838cb50f232df3ed) from GIT Leia - emitter took 
 0.343000 seconds
 "
 The error before was caused by him using wrong Review Board login user 
 name :-) The error message was so vague though, that we found out by 
 accident just recently. We will try to work with it further, but we would 
 still rather have the browser form working...



 Dne středa 17. června 2020 4:33:24 UTC+2 Christian Hammond napsal(a):
>
> We don't talk directly to the repository, or clone it, so that error
> probably isn't related to us?
>
> We communicate solely with the GitLab API, and we're using the
> standard GitLab API calls. We know that the authentication is working via
> those calls, because you'd get an error much earlier. If it's failing to
> fetch the commits, that's something that other tools are going to hit as
> well. It's GitLab blocking something when accessing that URL.
>
> Perhaps you can try making equivalent calls from the command line.
> We're calling the /api/v4/projects//repository/commits/ 
> API,
> with a "PRIVATE-TOKEN: " header. It appears Review Board is getting a
> 404 when that happens. An API call made by, say, `curl`, or Postman
>  should see the same behavior with the same
> credentials.
>
> The private token we use is the one provided when authorizing against
> the repository in the repository form (click Edit Credentials to change
> this token).
>
> Christian
>
> On Tue, Jun 16, 2020 at 6:19 AM kort...@email.cz 
> wrote:
>
>> I just found:
>> "cloning per https is blocked from the internet, if you want to
>> clone from internet you need to use ssh"
>> That seems like the real problem...
>> sooo... How 

Re: Reviewboard showing only 20 branches of gitlab repository

[Christian Hammond]

Well, I was hoping to get this for you for the upcoming release, but it
won't be possible. The GitLab Commit Diff API is busted. It doesn't return
a valid diff.

What the API does provide is the modified contents of each file, the
payload portion of a diff, but without all of the identifying information.
That is, a Git diff must have:

diff --git a/filename b/filename
index blobsha...blobsha filemode
--- a/filename
+++ b/filename

prior to any of the modified lines and their headers. Their API does not
provide this.

The API does provide metadata on the filenames and file mode, but it
doesn't provide the blob SHAs (not even short ones — though a long one
is* absolutely
required*), which are needed in order to actually fetch file contents.

You might want to pass this along to the GitLab contact there. Without
either a full, valid Git diff, or *all* the information needed to
reconstruct the header, we cannot use that API.

I've also found bug reports stating that their Diff API truncates long
files, which will be a deal-breaker. Here's one ignored bug on the issue:
https://gitlab.com/gitlab-org/gitlab-foss/-/issues/57702

And yes, it does seem that a personal access token can no longer get the
diff we accessed before. This hasn't come up before because most people use
RBTools. That'll have to be the recommendation here for now. We'll have to
turn off posting commits from the Review Board UI in the next release until
GitLab introduces a usable, stable API for this.

Christian

On Mon, Jun 22, 2020 at 7:49 PM Christian Hammond 
wrote:

> Authorization is performed by setting a PRIVATE-TOKEN:  header
> with the token you provide for the account (which must have all necessary
> permissions for the API).
>
> When listing the commits, we send:
>
> GET /api/v4/repository/commits?per_page=21&ref_name=master
>
> (Replace "master" with whatever branch you've selected.)
>
> When fetching an individual commit (after clicking a commit to post), we
> may or may not send the following, depending on prior cached information:
>
> GET /api/v4/repository/commits/
>
> We then fetch the repository information, based on your configuration:
>
> GET /api/v4/projects/
>
> (The repository ID is cached permanently in your Review Board repository
> entry's extra_data field under "gitlab_project_id" — if that's incorrect
> for any reason, you'll hit issues. If that's missing from extra_data, it
> will be refetched/cached based on the configured repository owner and name.)
>
> From that payload, we pull out the "path_with_namespace" parameter and
> then perform:
>
> GET /commit/.diff?private_token=
>
>
> It's this call that's failing. I noticed we're using ?private_token= query
> parameter here instead of the HTTP header. GitLab API docs claim this is
> still valid for the API, but maybe it's not working here? We have other
> GitLab customers who are using Review Board, but most people use RBTools,
> which doesn't use this request. So there could be something there.
>
> Or the auth token isn't able to access this resource. I should note we've
> had issues in the past where a previously-accessible resource has become
> unavailable. Perhaps that's happened.
>
> Now, when we wrote this support, GitLab did not have an API available to
> access the raw diff contents, so we had to go this route. I don't think
> this is the right move anymore, and an API has since been added. We'll work
> to move onto the new diff API. Perhaps this will solve the problem.
>
> Christian
>
>
> On Mon, Jun 22, 2020 at 2:12 AM korta...@email.cz 
> wrote:
>
>> The GitLab support would like to see which commands are sent from your
>> side, so they can identify what is wrong.
>>
>> Dne sobota 20. června 2020 5:13:40 UTC+2 Christian Hammond napsal(a):
>>>
>>> All the GitLab API commands? No, we don't log that I'm afraid. What do
>>> you want to see out of it?
>>>
>>> Christian
>>>
>>> On Wed, Jun 17, 2020 at 3:49 AM kort...@email.cz 
>>> wrote:
>>>
 Is it possible to see in Review Board dump of all executed API
 commands?

 Dne středa 17. června 2020 12:45:13 UTC+2 kort...@email.cz napsal(a):
>
> I finally got to someone competent on the GitLab side, so maybe we
> will get somewhere... His first idea is that the credentials management is
> somehow incompatible between review board and our GitLab. He is
> investigating now.
>
> Meanwhile we succeeded in using the RBTools to some extent. We don't
> have a review yet, but it seems the colleague was able to do a fetch
> operation successfully:
> "
>
> /r/41/diff/1/fragment/20/ - root - Fetching file 
> 'Project/Emitter_Unit/source/application/Communication/TimeSynchronization/CServerUDP.cpp'
>  rf26817a5f5799a477b0d858b135781470b41 (base commit ID 
> 9ba489121bb89c93900020b3838cb50f232df3ed) from GIT Leia - emitter took 
> 0.343000 seconds
> "
> The error before was caused by him using wrong Review B

Re: Reviewboard showing only 20 branches of gitlab repository

[Christian Hammond]

And I wondered why I was feeling Deja Vu over this. I filed a bug about
exactly this a year ago:

https://gitlab.com/gitlab-org/gitlab-foss/-/issues/56532

Feel free to send that to the support agent handling your case. We can't do
a thing until they address this issue (and some Google searches show others
are frustrated by it as well).

Christian

On Mon, Jun 22, 2020 at 10:42 PM Christian Hammond 
wrote:

> Well, I was hoping to get this for you for the upcoming release, but it
> won't be possible. The GitLab Commit Diff API is busted. It doesn't return
> a valid diff.
>
> What the API does provide is the modified contents of each file, the
> payload portion of a diff, but without all of the identifying information.
> That is, a Git diff must have:
>
> diff --git a/filename b/filename
> index blobsha...blobsha filemode
> --- a/filename
> +++ b/filename
>
> prior to any of the modified lines and their headers. Their API does not
> provide this.
>
> The API does provide metadata on the filenames and file mode, but it
> doesn't provide the blob SHAs (not even short ones — though a long one is* 
> absolutely
> required*), which are needed in order to actually fetch file contents.
>
> You might want to pass this along to the GitLab contact there. Without
> either a full, valid Git diff, or *all* the information needed to
> reconstruct the header, we cannot use that API.
>
> I've also found bug reports stating that their Diff API truncates long
> files, which will be a deal-breaker. Here's one ignored bug on the issue:
> https://gitlab.com/gitlab-org/gitlab-foss/-/issues/57702
>
> And yes, it does seem that a personal access token can no longer get the
> diff we accessed before. This hasn't come up before because most people use
> RBTools. That'll have to be the recommendation here for now. We'll have to
> turn off posting commits from the Review Board UI in the next release until
> GitLab introduces a usable, stable API for this.
>
> Christian
>
> On Mon, Jun 22, 2020 at 7:49 PM Christian Hammond <
> christ...@beanbaginc.com> wrote:
>
>> Authorization is performed by setting a PRIVATE-TOKEN: 
>> header with the token you provide for the account (which must have all
>> necessary permissions for the API).
>>
>> When listing the commits, we send:
>>
>> GET /api/v4/repository/commits?per_page=21&ref_name=master
>>
>> (Replace "master" with whatever branch you've selected.)
>>
>> When fetching an individual commit (after clicking a commit to post), we
>> may or may not send the following, depending on prior cached information:
>>
>> GET /api/v4/repository/commits/
>>
>> We then fetch the repository information, based on your configuration:
>>
>> GET /api/v4/projects/
>>
>> (The repository ID is cached permanently in your Review Board repository
>> entry's extra_data field under "gitlab_project_id" — if that's incorrect
>> for any reason, you'll hit issues. If that's missing from extra_data, it
>> will be refetched/cached based on the configured repository owner and name.)
>>
>> From that payload, we pull out the "path_with_namespace" parameter and
>> then perform:
>>
>> GET /commit/.diff?private_token=
>>
>>
>> It's this call that's failing. I noticed we're using ?private_token=
>> query parameter here instead of the HTTP header. GitLab API docs claim this
>> is still valid for the API, but maybe it's not working here? We have other
>> GitLab customers who are using Review Board, but most people use RBTools,
>> which doesn't use this request. So there could be something there.
>>
>> Or the auth token isn't able to access this resource. I should note we've
>> had issues in the past where a previously-accessible resource has become
>> unavailable. Perhaps that's happened.
>>
>> Now, when we wrote this support, GitLab did not have an API available to
>> access the raw diff contents, so we had to go this route. I don't think
>> this is the right move anymore, and an API has since been added. We'll work
>> to move onto the new diff API. Perhaps this will solve the problem.
>>
>> Christian
>>
>>
>> On Mon, Jun 22, 2020 at 2:12 AM korta...@email.cz 
>> wrote:
>>
>>> The GitLab support would like to see which commands are sent from your
>>> side, so they can identify what is wrong.
>>>
>>> Dne sobota 20. června 2020 5:13:40 UTC+2 Christian Hammond napsal(a):

 All the GitLab API commands? No, we don't log that I'm afraid. What do
 you want to see out of it?

 Christian

 On Wed, Jun 17, 2020 at 3:49 AM kort...@email.cz 
 wrote:

> Is it possible to see in Review Board dump of all executed API
> commands?
>
> Dne středa 17. června 2020 12:45:13 UTC+2 kort...@email.cz napsal(a):
>>
>> I finally got to someone competent on the GitLab side, so maybe we
>> will get somewhere... His first idea is that the credentials management 
>> is
>> somehow incompatible between review board and our GitLab. He is
>> investigating now.

Re: Reviewboard showing only 20 branches of gitlab repository

[korta...@email.cz]

This finally sounds like we are getting somewhere :-) Thank you very much 
for the investigation.

First reaction from the Gitlab side is:
"

Well, it seems that they are using API token for non-API urls. That's not 
allowed (since one ot the many security updates). Therefore it can work 
only with public projects which don't protect these paths at all...

Not sure how they want to solve it other than clone the repository instead 
of using gitlab web URLs...
"

I asked them if that means that the behavior you described it is not a bug, 
but a feature... Waiting for their answer...


Dne úterý 23. června 2020 7:49:49 UTC+2 Christian Hammond napsal(a):
>
> And I wondered why I was feeling Deja Vu over this. I filed a bug about 
> exactly this a year ago:
>
> https://gitlab.com/gitlab-org/gitlab-foss/-/issues/56532
>
> Feel free to send that to the support agent handling your case. We can't 
> do a thing until they address this issue (and some Google searches show 
> others are frustrated by it as well).
>
> Christian
>
> On Mon, Jun 22, 2020 at 10:42 PM Christian Hammond  > wrote:
>
>> Well, I was hoping to get this for you for the upcoming release, but it 
>> won't be possible. The GitLab Commit Diff API is busted. It doesn't return 
>> a valid diff.
>>
>> What the API does provide is the modified contents of each file, the 
>> payload portion of a diff, but without all of the identifying information. 
>> That is, a Git diff must have:
>>
>> diff --git a/filename b/filename
>> index blobsha...blobsha filemode
>> --- a/filename
>> +++ b/filename
>>
>> prior to any of the modified lines and their headers. Their API does not 
>> provide this.
>>
>> The API does provide metadata on the filenames and file mode, but it 
>> doesn't provide the blob SHAs (not even short ones — though a long one is* 
>> absolutely 
>> required*), which are needed in order to actually fetch file contents.
>>
>> You might want to pass this along to the GitLab contact there. Without 
>> either a full, valid Git diff, or *all* the information needed to 
>> reconstruct the header, we cannot use that API.
>>
>> I've also found bug reports stating that their Diff API truncates long 
>> files, which will be a deal-breaker. Here's one ignored bug on the issue: 
>> https://gitlab.com/gitlab-org/gitlab-foss/-/issues/57702
>>
>> And yes, it does seem that a personal access token can no longer get the 
>> diff we accessed before. This hasn't come up before because most people use 
>> RBTools. That'll have to be the recommendation here for now. We'll have to 
>> turn off posting commits from the Review Board UI in the next release until 
>> GitLab introduces a usable, stable API for this.
>>
>> Christian
>>
>> On Mon, Jun 22, 2020 at 7:49 PM Christian Hammond > > wrote:
>>
>>> Authorization is performed by setting a PRIVATE-TOKEN:  
>>> header with the token you provide for the account (which must have all 
>>> necessary permissions for the API).
>>>
>>> When listing the commits, we send:
>>>
>>> GET /api/v4/repository/commits?per_page=21&ref_name=master
>>>
>>> (Replace "master" with whatever branch you've selected.)
>>>
>>> When fetching an individual commit (after clicking a commit to post), we 
>>> may or may not send the following, depending on prior cached information:
>>>
>>> GET /api/v4/repository/commits/
>>>
>>> We then fetch the repository information, based on your configuration:
>>>
>>> GET /api/v4/projects/
>>>
>>> (The repository ID is cached permanently in your Review Board repository 
>>> entry's extra_data field under "gitlab_project_id" — if that's incorrect 
>>> for any reason, you'll hit issues. If that's missing from extra_data, it 
>>> will be refetched/cached based on the configured repository owner and name.)
>>>
>>> From that payload, we pull out the "path_with_namespace" parameter and 
>>> then perform:
>>>
>>> GET 
>>> /commit/.diff?private_token=
>>>
>>>
>>> It's this call that's failing. I noticed we're using ?private_token= 
>>> query parameter here instead of the HTTP header. GitLab API docs claim this 
>>> is still valid for the API, but maybe it's not working here? We have other 
>>> GitLab customers who are using Review Board, but most people use RBTools, 
>>> which doesn't use this request. So there could be something there.
>>>
>>> Or the auth token isn't able to access this resource. I should note 
>>> we've had issues in the past where a previously-accessible resource has 
>>> become unavailable. Perhaps that's happened.
>>>
>>> Now, when we wrote this support, GitLab did not have an API available to 
>>> access the raw diff contents, so we had to go this route. I don't think 
>>> this is the right move anymore, and an API has since been added. We'll work 
>>> to move onto the new diff API. Perhaps this will solve the problem.
>>>
>>> Christian
>>>
>>>
>>> On Mon, Jun 22, 2020 at 2:12 AM kort...@email.cz  <
>>> kort...@email.cz > wrote:
>>>
 The GitLab support would like t

Re: Reviewboard showing only 20 branches of gitlab repository

[Christian Hammond]

Yeah, it wasn't until I dug into this again (and actually wrote 95% of a
patch for the Diff API) that I realized I had done all this investigation
(and patch writing) already.

It's not a bug on their end. It's an intentional change. However, it's a
change that didn't have an equivalent for those that needed diffs from a
commit.

Here's the ticket in question for the change in behavior:
https://gitlab.com/gitlab-org/gitlab-foss/-/issues/50319

They were addressing a security issue, working to prevent an API token from
accessing data that shouldn't have been available. In the ticket,
they discuss the fact that there are many useful sets of data on GitLab
that do not have an API equivalent, and discussed whitelisting. Diffs,
unfortunately, were never whitelisted
.

If the repository is public, we can still fetch the diff. It only fails for
private repositories.

Sometime around then (I don't know the timeframe), they introduced the API
for getting a commit's diff, but it didn't seem designed so much as thrown
together. It doesn't produce anything resembling a usable diff for anything
but the simplest of tools. It truncates diffs (this may have changed, but
it's the most recent information I could find). It's inefficient (it
serializes as JSON). And it forces UTF-8 encoding (since it was serialized
as JSON) which will result in patching issues for many codebases (we've
been down this road before).

So basically, in order for us to support posting a commit through the New
Review Request page for GitLab, we need one of the following, in order of
preference:

1. A formal API for fetching the *raw* and *full* byte-level contents of a
diff for a commit, unmodified. Ideally not broken up into any files or
requiring pagination. Just the full thing you'd normally get from a `git
diff --full-index` command.
2. Whitelisting of the URL we're accessing for fetching the diff.
3. Fixing the current Commit Diff API to include a full Git diff header
(important: *with* long SHAs, not short SHAs, or we're back to square one)
and to not truncate or modify any diff contents.

What we're doing right now is preparing a change for 3.0.18 that will at
least make this situation less confusing. If we detect the circumstances
you're hitting, we display an error message explaining the situation, and
linking to a knowledge base article
 on
this. Best we can do until there's support in GitLab for this.

Christian

On Tue, Jun 23, 2020 at 2:48 AM korta...@email.cz  wrote:

> This finally sounds like we are getting somewhere :-) Thank you very much
> for the investigation.
>
> First reaction from the Gitlab side is:
> "
>
> Well, it seems that they are using API token for non-API urls. That's not
> allowed (since one ot the many security updates). Therefore it can work
> only with public projects which don't protect these paths at all...
>
> Not sure how they want to solve it other than clone the repository instead
> of using gitlab web URLs...
> "
>
> I asked them if that means that the behavior you described it is not a
> bug, but a feature... Waiting for their answer...
>
>
> Dne úterý 23. června 2020 7:49:49 UTC+2 Christian Hammond napsal(a):
>>
>> And I wondered why I was feeling Deja Vu over this. I filed a bug about
>> exactly this a year ago:
>>
>> https://gitlab.com/gitlab-org/gitlab-foss/-/issues/56532
>>
>> Feel free to send that to the support agent handling your case. We can't
>> do a thing until they address this issue (and some Google searches show
>> others are frustrated by it as well).
>>
>> Christian
>>
>> On Mon, Jun 22, 2020 at 10:42 PM Christian Hammond <
>> chri...@beanbaginc.com> wrote:
>>
>>> Well, I was hoping to get this for you for the upcoming release, but it
>>> won't be possible. The GitLab Commit Diff API is busted. It doesn't return
>>> a valid diff.
>>>
>>> What the API does provide is the modified contents of each file, the
>>> payload portion of a diff, but without all of the identifying information.
>>> That is, a Git diff must have:
>>>
>>> diff --git a/filename b/filename
>>> index blobsha...blobsha filemode
>>> --- a/filename
>>> +++ b/filename
>>>
>>> prior to any of the modified lines and their headers. Their API does not
>>> provide this.
>>>
>>> The API does provide metadata on the filenames and file mode, but it
>>> doesn't provide the blob SHAs (not even short ones — though a long one is* 
>>> absolutely
>>> required*), which are needed in order to actually fetch file contents.
>>>
>>> You might want to pass this along to the GitLab contact there. Without
>>> either a full, valid Git diff, or *all* the information needed to
>>> reconstruct the header, we cannot use that API.
>>>
>>> I've also found bug reports stating that their Diff API truncates long
>>> files, which will be a deal-breaker. Here's one ignored bug on the issue:
>>> https://gitlab.com/gi

Re: Reviewboard showing only 20 branches of gitlab repository

[korta...@email.cz]

I think we are on the end of the road. The last statement from GitLab guys:
"

We're not planning to work on this.

What about the possibility #4 - fetch the git repository?
"
I don't suppose possibility #4 will work for you. So there goes using a 
convenient way of code review :-/

There is still the RBTools left. Unfortunately the guy who should have 
tested it just went for paternal leave. I will try to find some time and 
test it myself.

In any case, thanks for you patient support and have a nice day:-)

Jiri Kortanek 

Unit tester/Team manager
Siemens, s.r.o.

Siemens Advanta Development

Dne úterý 23. června 2020 12:48:57 UTC+2 Christian Hammond napsal(a):
>
> Yeah, it wasn't until I dug into this again (and actually wrote 95% of a 
> patch for the Diff API) that I realized I had done all this investigation 
> (and patch writing) already.
>
> It's not a bug on their end. It's an intentional change. However, it's a 
> change that didn't have an equivalent for those that needed diffs from a 
> commit.
>
> Here's the ticket in question for the change in behavior: 
> https://gitlab.com/gitlab-org/gitlab-foss/-/issues/50319
>
> They were addressing a security issue, working to prevent an API token 
> from accessing data that shouldn't have been available. In the ticket, 
> they discuss the fact that there are many useful sets of data on GitLab 
> that do not have an API equivalent, and discussed whitelisting. Diffs, 
> unfortunately, were never whitelisted 
> .
>
> If the repository is public, we can still fetch the diff. It only fails 
> for private repositories.
>
> Sometime around then (I don't know the timeframe), they introduced the API 
> for getting a commit's diff, but it didn't seem designed so much as thrown 
> together. It doesn't produce anything resembling a usable diff for anything 
> but the simplest of tools. It truncates diffs (this may have changed, but 
> it's the most recent information I could find). It's inefficient (it 
> serializes as JSON). And it forces UTF-8 encoding (since it was serialized 
> as JSON) which will result in patching issues for many codebases (we've 
> been down this road before).
>
> So basically, in order for us to support posting a commit through the New 
> Review Request page for GitLab, we need one of the following, in order of 
> preference:
>
> 1. A formal API for fetching the *raw* and *full* byte-level contents of 
> a diff for a commit, unmodified. Ideally not broken up into any files or 
> requiring pagination. Just the full thing you'd normally get from a `git 
> diff --full-index` command.
> 2. Whitelisting of the URL we're accessing for fetching the diff.
> 3. Fixing the current Commit Diff API to include a full Git diff header 
> (important: *with* long SHAs, not short SHAs, or we're back to square 
> one) and to not truncate or modify any diff contents.
>
> What we're doing right now is preparing a change for 3.0.18 that will at 
> least make this situation less confusing. If we detect the circumstances 
> you're hitting, we display an error message explaining the situation, and 
> linking to a knowledge base article 
>  on 
> this. Best we can do until there's support in GitLab for this.
>
> Christian
>
> On Tue, Jun 23, 2020 at 2:48 AM kort...@email.cz  <
> kort...@email.cz > wrote:
>
>> This finally sounds like we are getting somewhere :-) Thank you very much 
>> for the investigation.
>>
>> First reaction from the Gitlab side is:
>> "
>>
>> Well, it seems that they are using API token for non-API urls. That's not 
>> allowed (since one ot the many security updates). Therefore it can work 
>> only with public projects which don't protect these paths at all...
>>
>> Not sure how they want to solve it other than clone the repository 
>> instead of using gitlab web URLs...
>> "
>>
>> I asked them if that means that the behavior you described it is not a 
>> bug, but a feature... Waiting for their answer...
>>
>>
>> Dne úterý 23. června 2020 7:49:49 UTC+2 Christian Hammond napsal(a):
>>>
>>> And I wondered why I was feeling Deja Vu over this. I filed a bug about 
>>> exactly this a year ago:
>>>
>>> https://gitlab.com/gitlab-org/gitlab-foss/-/issues/56532
>>>
>>> Feel free to send that to the support agent handling your case. We can't 
>>> do a thing until they address this issue (and some Google searches show 
>>> others are frustrated by it as well).
>>>
>>> Christian
>>>
>>> On Mon, Jun 22, 2020 at 10:42 PM Christian Hammond <
>>> chri...@beanbaginc.com> wrote:
>>>
 Well, I was hoping to get this for you for the upcoming release, but it 
 won't be possible. The GitLab Commit Diff API is busted. It doesn't return 
 a valid diff.

 What the API does provide is the modified contents of each file, the 
 payload portion of a diff, but without all of the identifying information. 
 That is, a Git d

Re: Reviewboard showing only 20 branches of gitlab repository

[korta...@email.cz]

Maybe one more thing - The adding of custom repository shows the 
"Environment can only contain strings" error. I know this is not a way that 
will help me, but still it seems like a bug worth solving to me...

Dne středa 24. června 2020 10:40:53 UTC+2 kort...@email.cz napsal(a):
>
> I think we are on the end of the road. The last statement from GitLab guys:
> "
>
> We're not planning to work on this.
>
> What about the possibility #4 - fetch the git repository?
> "
> I don't suppose possibility #4 will work for you. So there goes using a 
> convenient way of code review :-/
>
> There is still the RBTools left. Unfortunately the guy who should have 
> tested it just went for paternal leave. I will try to find some time and 
> test it myself.
>
> In any case, thanks for you patient support and have a nice day:-)
>
> Jiri Kortanek 
>
> Unit tester/Team manager
> Siemens, s.r.o.
>
> Siemens Advanta Development
>
> Dne úterý 23. června 2020 12:48:57 UTC+2 Christian Hammond napsal(a):
>>
>> Yeah, it wasn't until I dug into this again (and actually wrote 95% of a 
>> patch for the Diff API) that I realized I had done all this investigation 
>> (and patch writing) already.
>>
>> It's not a bug on their end. It's an intentional change. However, it's a 
>> change that didn't have an equivalent for those that needed diffs from a 
>> commit.
>>
>> Here's the ticket in question for the change in behavior: https://gitlab.com/gitlab-or
>>
>

-- 
Supercharge your Review Board with Power Pack: 
https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: 
https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
--- 
You received this message because you are subscribed to the Google Groups 
"Review Board Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/reviewboard/dc74c041-a23b-4e13-8c66-93fc452b8b00o%40googlegroups.com.

Re: Reviewboard showing only 20 branches of gitlab repository

[Christian Hammond]

That's a shame... Unfortunately, that's been consistent with all of our
years of experience integrating with GitLab's services. Things get
implemented in a broken or semi-useless state, and then ignored until
they're removed or made backward-incompatible suddenly one day. The reason
for the initial issue mentioned in the subject (the limit of 100 branches)
was due to their API not supporting pagination for many years (or, when
they did, it was often buggy). These API limitations in GitLab are going to
affect any tool that needs to access a diff from it.

A custom repository won't work. People are often surprised to hear this,
but Git has no suitable remote API. Their protocol covers very little
behind what's needed for a push/pull. Review Board has to talk to the API
of any Git-providing service, and that API has to provide a base set of
functionality.

RBTools is really just the way to go. It's what most Review Board users use
anyway, and is far more useful than browsing for commits will ever be,
since you can amend/add commits locally and keep updating your review
request, something you can't do if you're first pushing to a central
repository.

Christian

On Wed, Jun 24, 2020 at 3:06 AM korta...@email.cz  wrote:

> Maybe one more thing - The adding of custom repository shows the
> "Environment can only contain strings" error. I know this is not a way that
> will help me, but still it seems like a bug worth solving to me...
>
> Dne středa 24. června 2020 10:40:53 UTC+2 kort...@email.cz napsal(a):
>>
>> I think we are on the end of the road. The last statement from GitLab
>> guys:
>> "
>>
>> We're not planning to work on this.
>>
>> What about the possibility #4 - fetch the git repository?
>> "
>> I don't suppose possibility #4 will work for you. So there goes using a
>> convenient way of code review :-/
>>
>> There is still the RBTools left. Unfortunately the guy who should have
>> tested it just went for paternal leave. I will try to find some time and
>> test it myself.
>>
>> In any case, thanks for you patient support and have a nice day:-)
>>
>> Jiri Kortanek
>>
>> Unit tester/Team manager
>> Siemens, s.r.o.
>>
>> Siemens Advanta Development
>>
>> Dne úterý 23. června 2020 12:48:57 UTC+2 Christian Hammond napsal(a):
>>>
>>> Yeah, it wasn't until I dug into this again (and actually wrote 95% of a
>>> patch for the Diff API) that I realized I had done all this investigation
>>> (and patch writing) already.
>>>
>>> It's not a bug on their end. It's an intentional change. However, it's a
>>> change that didn't have an equivalent for those that needed diffs from a
>>> commit.
>>>
>>> Here's the ticket in question for the change in behavior: https://gitlab.com/gitlab-or
>>>
>> --
> Supercharge your Review Board with Power Pack:
> https://www.reviewboard.org/powerpack/
> Want us to host Review Board for you? Check out RBCommons:
> https://rbcommons.com/
> Happy user? Let us know! https://www.reviewboard.org/users/
> ---
> You received this message because you are subscribed to the Google Groups
> "Review Board Community" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to reviewboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/reviewboard/dc74c041-a23b-4e13-8c66-93fc452b8b00o%40googlegroups.com
> 
> .
>


-- 
Christian Hammond
President/CEO of Beanbag 
Makers of Review Board 

-- 
Supercharge your Review Board with Power Pack: 
https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: 
https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
--- 
You received this message because you are subscribed to the Google Groups 
"Review Board Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/reviewboard/CAE7VndnoZOH0uJ%2B7fgPfkPrSxP6GqA44ZRu5gEnp9D3zW6mwBg%40mail.gmail.com.