сб, 9 нояб. 2019 г. в 21:50, Ben Cooksley <bcooks...@kde.org>: > > > Over the past number of years one of the tasks the Sysadmin team has > > > worked on has been improving the overall maintainability of our > > > systems, with a significant number of specialised cronjobs, exceptions > > > and hidden linkages being eliminated. > > > > > > That is with one great exception: api.kde.org and ebn.kde.org. > > > > > > Both of these are suffering from an extreme amount of digital bitrot > > > and special casing and in general are now in a condition where I > > > cannot say for certain whether it would be possible to replicate the > > > setup on a new system without us experiencing some degree of breakage > > > (some of which we may not discover until weeks/months afterwards). > > > > > > In addition, the current setup relies on an old-fashioned overnight > > > reprocessing of all repositories, which is inefficient and resource > > > expensive. A more modern approach would have the various projects api > > > documentation generated on a delayed cycle from relevant branches as > > > part of something like a CI job (but not part of the actual CI > > > workflow itself).
Hi Ben, I can't discuss this topic before we understand what exactly is wrong with api.kde.org and ebn.kde.org and why they are hard to manage. Could you please describe the current situation (where to find source code, how many servers, etc) in new Phabricator tasks like you did for identity.kde.org in https://phabricator.kde.org/T8449 ? P.S. Complicated legacy systems can be easy to replicate once you automate their deployment by using Docker containers and/or configuration management software like Ansible. -- Alexander Potashev
