agama-project / agama / 18222230338 / 3 – service
66%
master: 81%

LAST BUILD BRANCH: fix_apply_network_changes
DEFAULT BRANCH: master
Ran
Files 390
Run time 9s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 88.568%. First build
service – 18222230338.3

push

github

web-flow 
feat: add a new config-based API

This pull request introduces two big changes:

* The implementation of the new HTTP API for the `l10n` module. Bear in
mind that the specification is still a work in progress.
* The new architecture for Agama services. The `l10n` module has been
heavily reorganized to:
  * support the new API.
  * make it easier to maintain in the future.

## The new HTTP API

Here is a brief explanation of how the new API should look like. For
further details, check [the ongoing
description](https://gist.github.com/joseivanlopez/ed9f4f87b214ff60d52a5f6c3897dc9d).

In general, it is designed around 3 main concepts:

* system: represents the current status of the running system. It is not
only about the configuration, but it can offer additional information
(e.g., the list of supported languages, products, hardware information,
etc.).
* config: represents the user configuration for the target system.
* proposal: represents what is going to happen during installation.

Here is the API summary (check whether we have done some changes):

~~~
GET             /system
GET             /extended_config
GET             /extended_config/{scope}
GET PUT PATCH   /config
GET PUT PATCH   /config/{scope}
GET POST PATCH  /questions
GET             /proposal
GET             /state
GET             /issues
POST            /action
~~~

This new design allows us to drastically reduce the complexity and the
amount of code needed by the old API.

Of course, we still need to extend it to support more use cases
(software, DASD, progress, etc.) but this one is a step in the direction
we want to take.

## The new architecture

Coming from a set of separate single-thread D-Bus services, we had have
time to identify a few limitations that we would like to overcome in
this redesign. Given that we expect several process to collaborate
(holding configuration, listening for system changes, etc.) we want to
implement something similar to an *very simplified* [actor
mod... (continued)

11257 of 12710 relevant lines covered (88.57%)

60.36 hits per line

Source Files on job service - 18222230338.3