On Wed, Nov 20, 2019 at 1:48 AM Harald Sitter <sit...@kde.org> wrote: > > On Mon, Nov 18, 2019 at 6:29 PM Ben Cooksley <bcooks...@kde.org> wrote: > > It'll be hard to tell whether a name is unique or not when creating a > > repository unfortunately. > > For the most part I do not expect collisions to occur though and we > > certainly won't aim to create duplicate names. > > Wouldn't creating a repo also include creating the repo-metadata file > for it? Through that it should be easy to assert uniqueness via a > server-side hook on repo-metadata.
Not necessarily. It will definitely be possible for a repository to exist on Gitlab but not in the repo-metadata repository. Any sync to repo-metadata would be a step taken after the repository is created on Gitlab. Ideally we would have an automated script sync the contents of repo-metadata after they're changed on Gitlab (ie. Gitlab is the authoritative source here) Having the repository come into existence after the repo-metadata entry can cause issues, although they appear fairly rarely as there is generally a delay between Sysadmin creating the repository and Developers starting to use a repository - hence why i'd like for the repository to appear first. > > In point of fact, if we fully flatten out the files I expect uniquness > would be implicit. > > e.g. > > repo-metadata/projects/blinken.yaml (repopath: kde/blinken) > repo-metadata/projects/kinfocenter.yaml (repopath: kde/kinfocenter > repo-metadata/projects/www-kde-org.yaml (repopath: sysadmin/www-kde-org) Website repositories, much like Sysadmin repositories, will continue to live in their own namespaces and therefore should not be flattened (if they're even included in repo-metadata, as they won't be under kde/) Please note that the repository paths for Blinken and KInfoCenter will be kde/edu/blinken and kde/plasma/kinfocenter respectively, as a degree of grouping is required on Gitlab for ease of visibility over merge requests and tasks (modules rarely change, and Gitlab handles redirecting old names to new names for us in any event even for Git clients) > > HS Cheers, Ben