Hi Harald, thank you! On 8/12/22 15:12, Harald Welte wrote: Cloning via https:// works, but doesn't via git:// $ git clone git://git.osmocom.org/libosmo-abis Cloning into 'libosmo-gprs'... fatal: remote error: access denied or repository not exported: /libosmo-gprs.git $ git clone https://git.osmocom.org/libosmo-gprs Cloning into 'libosmo-gprs'... Fetching objects: 193, done. Best regards, Vadim. -- - Vadim Yanitskiy <vyanitskiy at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

Hi Harald, On 8/12/22 18:26, Harald Welte wrote: this way we need to invest some additional time into git-to-https migration, because, as I mentioned earlier, both Coverity [1] and Jenkins [2] are still using git://. And currently both are failing when trying to clone libosmo-gprs.git, see: [1] https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/1698/ [2] https://jenkins.osmocom.org/jenkins/job/gerrit-osmo-pcu/2430/ The main problem with using Gitea is that all projects are grouped: we have 'osmocom', 'cellular-infrastructure', 'phone-side', and more. This is why we cannot simply do s#git://git#https://gitea#. To overcome this problem, we could clone/pull from Gerrit instead. But this is not going to work for projects not present in Gerrit... :/ Best regards, Vadim. -- - Vadim Yanitskiy <vyanitskiy at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

Hi Harald, On 8/13/22 02:53, Vadim Yanitskiy wrote: I found your https://gerrit.osmocom.org/c/osmo-ci/+/28349 and fixed problems found during code review. Oliver gave CR+2, so I merged it. Now osmo-ci.git is using https:// instead of git://, so libosmo-gprs.git is now accessible by Jenkins jobs. But we're not doing good yet. == cgit is out of sync Today I noticed that cgit mirror of libosmo-gprs.git is out of sync with Gerrit/Gitea: $ git ls-remote https://git.osmocom.org/libosmo-gprs HEAD 11cbba9d9dd3423959adc6cd9200fe1ce9afd227 HEAD $ git ls-remote https://gerrit.osmocom.org/libosmo-gprs HEAD 147c95f09f5c222d8e1384d131781d8ae4cbd3d8 HEAD git ls-remote https://gitea.osmocom.org/osmocom/libosmo-gprs HEAD 147c95f09f5c222d8e1384d131781d8ae4cbd3d8 HEAD The sync worked until recently: I merged several changes via Gerrit, and they do appear at https://cgit.osmocom.org/libosmo-gprs/log/. Is there anything I could do to troubleshoot this? == Sporadic git-clone failures on Jenkins Another problem is that after the git-to-https migration, I started to observe sporadic git-clone failures in master Jenkins jobs like: + git clone https://git.osmocom.org/libosmo-abis libosmo-abis Cloning into 'libosmo-abis'... error: (curl_result = 56, http_code = 200, sha1 = 6498826eae07a02be1afc8e4f161bd1caa626e7d) error: Unable to find 6498826eae07a02be1afc8e4f161bd1caa626e7d under https://git.osmocom.org/libosmo-abis Cannot obtain needed tree 6498826eae07a02be1afc8e4f161bd1caa626e7d while processing commit e58d33153dd2bed3629b9a09fd6add58f296bd6a. error: fetch failed. + git clone https://git.osmocom.org/libosmo-sccp libosmo-sccp Cloning into 'libosmo-sccp'... error: HTTP/2 stream 0 was closed cleanly, but before getting all response header fields, treated as error (curl_result = 92, http_code = 0, sha1 = 80f1e4bfb9c161c76f04443bd03b8a2c3ce7dbd5) error: HTTP/2 stream 0 was closed cleanly, but before getting all response header fields, treated as error (curl_result = 92, http_code = 0, sha1 = 7be9bdd1632efe63b9af2d42dd355eda7883747c) error: Unable to find 7be9bdd1632efe63b9af2d42dd355eda7883747c under https://git.osmocom.org/libosmo-sccp Cannot obtain needed blob 7be9bdd1632efe63b9af2d42dd355eda7883747c while processing commit e7c8067df026fd294af2c95fbd2ceb16eeab7d74. error: fetch failed. Looks like our cgit instance is unreliable when accessed via https://. Best regards, Vadim. -- - Vadim Yanitskiy <vyanitskiy at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

On Thu, Aug 18, 2022 at 11:48:05AM +0200, Oliver Smith wrote: Cloning from gerrit also makes sense because there is no delay between pushing/merging and the repos being updated. But, I understand the idea behind gitea was that users can create their own repositories. If we use gerrit as the git source for CI, we deny all user created repositories the possibility of using osmo-ci infrastructire. So I'm not sure that we want gerrit to be regarded as the primary repository; though it de-facto already is for most active projects. (I have nostalgia for the times when git.osmocom.org was the only place for repositories.) I'm not sure what the intention is at the moment, i.e. which is the one definitive primary git: Is it gitea.osmocom.org? Those are mostly mirrors of gerrit. There is often a delay between merging patches (gerrit) and seeing them here. Is it git.osmocom.org? Served by cgit and labeled "Legacy mirror" There is often a delay between merging patches (gerrit) and seeing them here. Is it gerrit.osmocom.org? Not all projects are there. Weird Java implementation of git, though works for all intents and purposes. Definitely not github/gitlab. ~N