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
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
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
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
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
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
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
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_name=master
(Replace "master" with whatever branch
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?
>
>
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
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
>
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
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
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
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
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
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
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
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
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
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
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.
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...
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
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.
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
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
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
28 matches
Mail list logo
