xapi-project / xen-api / 42356554120
79%

DEFAULT BRANCH: master
Ran
Jobs 1
Files 36
Run time 1min
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: 78.996%. Remained the same
42356554120

push

github

web-flow 
XCPNG-3989: Commit message list upstream (#7361)

This is a proof-of-concept of catching various breaking changes to
XenAPI. This is quite a niche safety net as it captures 2 cases that
aren't captured by the building of Xapi:

- Permuting parameter order: if you swap the order of parameters (within
the required prefix or optional suffix - enforced by another check),
this will silently break every client. The corresponding code can remain
unchanged because the generated dispatcher invokes the API using
labelled arguments (can be applied in any order).
- Changing a defaulted parameter's value: rare, but this is now detected
and must be explicitly noted.

Other larger changes will have to be confronted when you attempt to
build the rest of Xapi. However, committing the message list upstream
has some idealistic benefits: (1) there's enough information in the
generated message listing to produce a typed XenAPI client (this is the
approach taken in my [xapy](https://github.com/contificate/xapy)
project, which uses the documentation's `xenapi.json` file), (2) by
committing messages upstream, it forces the repository state and commits
to be obvious about what messages have been changed (along with the
possibility, in future, of easily seeing what messages are present
between version tags, as they'll be noted upstream).

---

This work was inspired by 0416e2ae8 (which I came across when
generalising optional arguments to permit omission anywhere). This PR
subsumes this check and also captures the part that was lacking: new
parameters are now detected by comparison against the committed message
list (snapshot), so it'll fail the build if you don't promote it (and
accept it as a breaking change to the API). Of course, doing such a
change requires changing the implementation code, but this makes PR
makes it obvious to the developer that they should provide defaults for
any new arguments they're appending to extant messages.

---

As an example of how this works:... (continued)

3667 of 4642 relevant lines covered (79.0%)

0.79 hits per line

Jobs
ID Job ID Ran Files Coverage
1 python3.11 - 42356554120.1 36
79.0
GitHub Action Run
Source Files on build 42356554120