Sysadmin Load Reduction: Code Related Services

[Ben Cooksley]

On Tue, Nov 19, 2019 at 1:34 AM Harald Sitter <sitter at kde.org> wrote:
>
> On Sat, Nov 16, 2019 at 9:40 PM Ben Cooksley <bcooksley at kde.org> wrote:
> >
> > On Sun, Nov 17, 2019 at 5:19 AM Carl Schwan <carl at carlschwan.eu> wrote:
> > >
> > > Hi all,
> >
> > Hi Carl,
> >
> > >
> > > Can the gitlab api be of useful in the future?
> > >
> > > e.g https://invent.kde.org/api/v4/groups/7
> >
> > While for many purposes Gitlab's API wil be perfectly fine, it doesn't
> > provide us with the i18n branch information which some users will
> > require.
>
> Something to perhaps consider at this point is to revise the
> repo-metadata format in general and offload data to gitlab?

Once we have transitioned repository hosting and code review to
Gitlab, restructuring how repo-metadata works was one of the items I
wanted to look into (if anything because i'd like to automate updates
to repo-metadata so we don't have to create them on Gitlab and then
register them in repo-metadata as a second separate step)

>
> Notably I'd kick the following yaml properties in favor of their
> literal replacements in gitlab: description, icon, members, name. On a

Nothing uses members, so once the XML is gone we can get rid of that completely.
Likewise, nothing uses icon either to my knowledge.

Description and Name should definitely both come from Gitlab.

> related note I guess there'd be need to figure out how to map from a
> "kde project" to a gitlab project. Currently the paths between
> repo-metadata and invent do not line up.

The 'repopath' key in repo-metadata will serve this purpose (it might
be missing the kde/ prefix though depending on how the implementation
ends up working out)
This fits into an overall discussion i'd like to have around
playground/release service/extragear in the Git world though which
will be brought up separately.

>
> Additionally we may able able to remove:
>
> - hasrepo (repopath==null implies this)

This can go yes.

> - repoactive (totally not sure what this communicates)

This is meant to indicate whether a given entry/repository should be
processed by CI and scripty.
We have a number of unmaintained and other infrastructural
repositories which both of those should ignore.

>
> And lastly, fold the i18n data into the yaml. Which I think means we
> could drop the excessive use of directories and just have one file per

I've no objection to this.

> project, e.g. projects/kde/workspace/sddm-kcm.yaml or perhaps even
> more ideally projects/sddm-kcm.yaml (because the current dir structure
> duplicates information encoded in repopath; so I would think either we
> should drop the property or flatten projects/).

We should mirror the repopath as in the Gitlab world it will be
possible for us to have two repositories that have the same name, just
in different parts of the tree.

>
> HS

Cheers,
Ben