With Repo V2.12 we cannot init our repository anymore

Rene Kempen

unread,

Mar 9, 2021, 7:26:31 AM3/9/21

to Repo and Gerrit Discussion

When we do a:
repo init -u ssh://<git credentials>/navpad-manifests.git -m master.xml --current-branch

we get this output:
... A new version of repo (2.12) is available.
... New version is available at: /var/jenkins-slave/workspace/italia-copy-platform-nightly-git/.repo/repo/repo
... The launcher is run from: /usr/local/bin/repo
!!! The launcher is not writable. Please talk to your sysadmin or distro
!!! to get an update installed.
Downloading manifest from ssh://<git credentials>/navpad-manifests.git
fatal: manifest 'master.xml' not available
fatal: <project> invalid "path": ./: bad component: .

Our manifest file master.xml contains this:
<manifest>
<remote name="origin" fetch="ssh://<git credentials>"/>
<default revision="refs/heads/master" remote="origin" sync-j="4"/>

<project name="navpad-main" remote="origin" path="./" revision="master"/>
<project name="navpad-navui" remote="origin" path="./apps/Imports/NavApp/" revision="develop"/>
<project name="navpad-navkit" remote="origin" path="./navkit/" revision="master"/>
<project name="navpad-michi" remote="origin" path="./michi/" revision="master"/>
<project name="navpad-prebuilt" remote="origin" path="./prebuilt/" revision="master"/>

<project name="navpad-manifests" remote="origin" path="./manifests" revision="master"/>
</manifest>

Somehow in v2.12 it is not allowed anymore to use the "./" in path.
When we remove the "./" in the above manifest file we see that the navpad-main project is deployed in the navpad-main directory, however we do not want it o be deployed in the navpad-main directory but in the current directory as if it was in the "./" directory.

how we can deplay the navpad-main project in the current directory "./" ?

Remy Bohmer

unread,

Mar 9, 2021, 8:22:05 AM3/9/21

to Rene Kempen, Repo and Gerrit Discussion

Hi,

Similar issue here: we have a pinned manifest repository that contains our releases, and we usually store that in the .repo/manifests/releases folder.

Users can then simply run a 'repo init -m releases/some-release.xml' to get that release manifest loaded. By using this 2 repository approach we do not pollute the project definition manifests repository with the output of a cicd pipeline while keeping the workflow easy for the developers who need to load a pinned manifest for some release.

This is a new restriction forced on top of the manifests structure, while it has been working fine for more than a decade.

What is the technical rationale to enforce such new restrictions?

Kind regards,

Remy

Op di 9 mrt. 2021 13:26 schreef Rene Kempen <rene....@tomtom.com>:

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/6c916387-bc31-485f-bf8c-2a89bfd89181n%40googlegroups.com.

Yaobin Wen

unread,

Mar 9, 2021, 10:52:12 AM3/9/21

to Repo and Gerrit Discussion

Take a look at the comment here: https://bugs.chromium.org/p/gerrit/issues/detail?id=14200#c1

The author said "but also we hadn't really expected anyone to be doing this... a project checked out into the root could create files under .repo/ directly thereby bypassing a number of security checks & user consent."

Reply all

Reply to author

Forward