An extra wrapper element was added
```
<lastcall>
<lastcall>2017-11-15</lastcall>
</lastcall>
```
Correct is one element with text for each item
```
<lastcall>2017-11-15</lastcall>
```
E.g. lastcall can exist more than once according to the schema, but only
one item was kept.
Before:
```yaml
lastcall: 2017-11-15
```
After:
```yaml
lastcall:
- 2021-03-30
- 2017-11-15
```
Github workflows tend to be verbose. This can make it difficult to determine why a failure occurs.
To help identify causes for validation failures, the output of the XEP-0001 conformance script should have a bit of color to highlight the important bits.
xmllint will return exit code 10 when an XPATH query finds no matches. With the changes in this commit, the script isn't stopped. Instead, it uses an empty value, which is likely to cause the validation checks (further down in the script) to fail.
As per @horazont's feedback:
> You do not need () around the command in an if. I think that causes a subshell to spawn, the effects of which I'm not certain about.
Further Googling suggests that the exit status of a pipeline is that of the most recently executed foreground pipeline, meaning that the exit code can be used directly in conditional statements.
As per @horazont's feedback: `-u` shouts at you if you use an undefined variable (very useful to catch typos)
and `-o pipefail` improves error handling by also failing if any of the commands in a pipe fail.
This adds a simple bash script that checks if a provided file (filename to be provided as first argument) conforms to XEP-0001.
Expected to be executed from the directory that holds all xep XML files.
Requires one argument: the file name of the xep to be validated, eg:
$ tools/validate-xep0001-conformance.sh xep-0010.xml
exit status will be non-zero upon validation failure.
requires: bash, xmllint
Don't remember why it did this here. There's another spot where it
removes longer stretches of whitespace. Doesn't trim leading or trailing
whitespace tho, but that's what breaks it here.
This pipeline features the following:
- Building of an nginx image with the XEPs as static files,
in all formats.
- Incremental builds on the main branch and incremental builds
for MRs based on the last main build.
- Automatic archiving of changed XEPs to the attic
- Automatic announcement to the mailing lists
If it is known that the documents have already been built or if it
is imperative to use the versions built even if local changes have
been applied since the last build, this switch comes in handy.
Sometimes the main working directory may have other XML files such as
the temporary files generated by TeXML (xep-*.tex.xml) which may be
picked up by the metadata script. Use a more specific pattern so that it
only extracts metadata from real XEP files.
