hermes harvest return 0 on error

[daniel-mohr]

Following Set up automatic software publishing I created a CITATION.cff and in the end in the pipeline the upload to zenodo sandbox fails with Error in 'hermes.deposit.publish' entry point 'invenio': With access_right open, a license is required..

The reason was that hermes harvest already claims:

!!! warning "CITATION.cff is not valid according to <https://citation-file-format.github.io/1.2.0/schema.json>"
    Invalid input for `root`.
    !!! message "'message' is a required property"

But still the command returned 0 and the pipeline passed. And for a user no error is recognizable.

I would suggest that hermes return an other value than 0 on error. Then the pipeline would break and the user is pointed to the error.

[led02]

You are right, even though we only get a warning during harvesting, we need to somehow signal / decide when we actually have an error (and signal this).

However, we are still not very happy with the different ways and rules that are applied for error processing: on the one hand, we want to be as resilient as possible. On the other hand, it's important to face the user with as much information as possible.

We're planning on producing an extensive HERMES runtime report using the Python logging facility. However, there are still some decitions to be taken:

• How are errors during processing signalled and who handels them?
• What errors should be treated as "fatal" and stop the processing pipeline (and at which "stage")? (I.e., it might be okay if some of the harvesters fail, as long as there is a consistent dataset produced... from time to time failing harvesters might even be helpful)
• How to produce a (user readable) extensive and understandable report?

[daniel-mohr]

I do not think that a harvesters should be allowed to fail. If the harvester if configured it should work. Otherwise a user can decide to use only some, e. g.:

[harvest]
from = [ "git" ]

[daniel-mohr]

Maybe it could also be interesting to provide the user a simple solution to check the cff file, e. g. as gitlab ci pipeline using cffconvert and an official docker image (The provided citationcff/cffconvert docker image is pretty old and based on an old alpine:3.14.1.):

cffconvert__alpine:
  stage: pre
  image:
    name: alpine:latest
  script:
    - date
    - cat /etc/os-release
    - apk add --no-cache py3-attrs py3-click py3-dateutil py3-docopt py3-jsonschema py3-packaging py3-parsing py3-pip py3-pykwalify py3-pyrsistent py3-requests py3-retrying py3-setuptools py3-six
    - pip3 install cffconvert
    - cffconvert --validate

Or using the pre-commit hook.

This could be mentioned in the documentation.

[led02]

In #253 there is a first fix to this. I.e., hermes exits with error code 1 when some command has an error (that might not be fatal), it stops with code 2 when there is an uncaught exception, otherwise the code will be 0.

This is behavior is still subject to change, follow up on issue #238