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 > <https://gitlab.com/gitlab-org/gitlab-foss/-/issues/56532>. > > 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 > <https://support.beanbaginc.com/support/solutions/articles/3000100782> 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 <javascript:> < > kort...@email.cz <javascript:>> 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/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 < >>>> chri...@beanbaginc.com> wrote: >>>> >>>>> Authorization is performed by setting a PRIVATE-TOKEN: <AUTH_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/<SHA> >>>>> >>>>> We then fetch the repository information, based on your configuration: >>>>> >>>>> GET /api/v4/projects/<repository_id> >>>>> >>>>> (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 >>>>> <path_with_namespace>/commit/<SHA>.diff?private_token=<AUTH_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 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' >>>>>>>>> rf26817a5eeeef5799a477b0d858b135781470b41 (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_id>/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 >>>>>>>>>> <https://www.postman.com/> 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. 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 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 < >>>>>>>>>>>>>>> ruze...@gmail.com> 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/ >>>>>>>>>>>>>>>> <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 <module>* >>>>>>>>>>>>>>>> * 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 <module>* >>>>>>>>>>>>>>>> * 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 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* >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Martin >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Dne pátek 22. května 2020 11:58:58 UTC+2 Christian Hammond >>>>>>>>>>>>>>>> napsal(a): >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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 kort...@email.cz < >>>>>>>>>>>>>>>>> kort...@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</a >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> <https://www.reviewboard.org/docs/rbtools/1.0/workflows/git/#rbtools-workflow-git> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- 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/18221594-db6f-4656-b5bf-726365bd7c10o%40googlegroups.com.
