Sysadmin Load Reduction: Code Related Services

[Carl Schwan]

Hi all,

Can the gitlab api be of useful in the future?

e.g https://invent.kde.org/api/v4/groups/7

Cheers,
Carl

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, November 16, 2019 9:51 AM, Ben Cooksley <bcooksley at kde.org> wrote:

> On Sat, Nov 16, 2019 at 10:39 PM Albert Astals Cid aacid at kde.org wrote:
> 

> > El dissabte, 16 de novembre de 2019, a les 10:14:15 CET, Ben Cooksley va escriure:
> > 

> > > 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.
> > 

> > Wait, are you saying we shouldn't be using that endpoint to solve our dependency on kde_projects.xml on scripty either?
> > I just asked Adrián to have a look at it, since it seemed easier than having to worry about downloading and keeping an up to date copy of another repo.
> 

> I was referring to the "implement kde_projects.xml" part of his email there.
> 

> The modern components of the projects.kde.org/api/ endpoint are of course fine.
> 

> > Cheers,
> > Albert
> 

> Cheers,
> Ben
> 

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

> > > > --
> > > > Alexander Potashev
> > > 

> > > Cheers,
> > > Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - carl at carlschwan.eu - 0x7F564CB5.asc
Type: application/pgp-keys
Size: 3195 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20191116/6c7e45b7/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 823 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20191116/6c7e45b7/attachment.sig>