Closed guusdk closed 1 year ago
It would be great to collect a list of specific criteria to check for, so that it can be more easily converted into an implementation. I'll try to make a start, and would extend it with everything that's posted later on. I'm annotating with "warning" for something that CI should complain about but not block a merge, and "error" for things that must not be accepted.
Root folder xep-*.xml
:
/xep/header/number
equals number in filename (error)/xep/header/revision
block in changed files, containing a version, date, initials and remark (warning)Inbox proto-XEPs:
/xep/header/number
is "xxxx" or "XXXX" (warning)/xep/header/status
is "ProtoXEP" (warning)Both types of XEP files:
/xep/header/type
is one of:
/xep/header/status
is one of:
Thank you Georg for the support!
For this issue I think the deliverable just needs to be a script that accepts (at a minimum) a XEP .xml file, and returns a formatted list of issues (if any). I don't think CI stuff should be in scope (therefore the person working on this does not need any knowledge of Github automation).
I reformulated this with a clearer specification in #1235 and #1240, in order to have a more clean issue log. Re-open this if you disagree or comment over there or have anything to add.
we should have a CI job which validates that changed or added files are conformant; e.g. that protoxeps come with the correct
<number>
and<status>
values.