Sysadmin Load Reduction: Code Related Services

[Ben Cooksley]

On Sat, Nov 16, 2019 at 3:58 PM Alexander Potashev <aspotashev at gmail.com> wrote:
>
> пт, 15 нояб. 2019 г. в 22:05, Ben Cooksley <bcooksley at kde.org>:
> >
> > On Sat, Nov 16, 2019 at 3:27 AM Alexander Potashev <aspotashev at gmail.com> wrote:
> > >
> > > пт, 15 нояб. 2019 г. в 15:46, Harald Sitter <sitter at kde.org>:
> > > >
> > > > On Sat, Nov 9, 2019 at 11:37 PM Alexander Potashev <aspotashev at gmail.com> wrote:
> > > > >
> > > > > сб, 9 нояб. 2019 г. в 02:51, Ben Cooksley <bcooksley at kde.org>:
> > > > > > In the category of no longer in use, we have the compatibility
> > > > > > generator for the kde_projects.xml file. This was introduced when we
> > > > > > shutdown Redmine/Chiliproject and migrated to Phabricator, as a way of
> > > > > > keeping services that needed to discover a list of KDE Projects
> > > > > > functional.
> > > > > >
> > > > > > As we've since migrated to using YAML files within the
> > > > > > sysadmin/repo-metadata repository for both the CI System and
> > > > > > kdesrc-build (and with LXR using kdesrc-build to do it's code
> > > > > > checkouts) there shouldn't to my knowledge be anything still relying
> > > > > > on this (aside from perhaps scripty).
> > > > > >
> > > > > > I'd therefore like to shut this generator down as well, along with the
> > > > > > compaibility redirector running at projects.kde.org (given that it has
> > > > > > been some time since we were using that site, and many projects have
> > > > > > moved around in the virtual structure since then, making the redirects
> > > > > > it is able to offer useless)
> > > > >
> > > > > Hi Ben,
> > > > >
> > > > > I am developing a new version of the "opensrc" plugin for Lokalize [1]
> > > > > and it currently depends on kde_projects.xml. Of course I can add new
> > > > > code to scan the Git repo instead of just fetching kde_projects.xml,
> > > > > however it would be more complicated.
> > > >
> > > > https://projects.kde.org/api/doc/ specifically deals with this problem
> > > > by abstracting the repo away behind a micro service.
> > >
> > > This looks like another view of the data available in
> > > kde_projects.xml, however the API is very limited. For example I can't
> > > query repo descriptions using this API. Thus not helpful.
> > >
> > > However if we were going to kill kde_projects.xml, are you sure
> > > projects.kde.org/api/ would be still available and not shut down as
> > > well?
> >
> > The API that Harald mentions is based off the YAML files, and is not
> > reliant on the legacy kde_projects.xml file.
>
> I can implement kde_projects.xml or a modernized version of it as part
> of projects.kde.org/api/. Does this sound like a good idea?
>
> We don't need to support the exact same XML format, so I would prefer
> a JSON listing all projects with all their properties, at something
> like GET https://projects.kde.org/api/v1/export or may be return all
> project properties in GET https://projects.kde.org/api/v1/projects

I'll leave it to Harald to comment on whether he'd be happy having
additional capabilities in the Projects Microservice API he maintains.
(Harald, I assume it's only requirement is a copy of the
sysadmin/repo-metadata repository locally, and it doesn't require the
actual Git repositories?)

We really should avoid continuing to keep legacy endpoints alive
though (as it is just shifting the maintenance effort of porting away
from it further down the road), especially for something that is going
to end up on end user systems.

On that note, should you be using QNetworkAccessManager, please ensure
you forcibly and explicitly enable handling of redirects.

>
> --
> Alexander Potashev

Cheers,
Ben