Use static AUTHORS files; add lint job to check mailmap and AUTHORS files
Description
The lal*/AUTHORS files are currently built dynamically; starting from the lal*/.AUTHORS files (which record names from the pre-Git history, copyright notices, etc.) and updating with names from the more recent Git history. This can only happen if the full repository is available, however, and this is not the case for the GitLab CI runnners which only check out a limited history. As a result the lal*/AUTHORS appear not to be updated, as pointed out in #613 (closed).
This MR addresses this by committing the lal*/AUTHORS files as part of the Git history, so that they are always available in GitLab CI jobs for building packages, documentation, etc. To ensure the lal*/AUTHORS files do not become out of date, a lint:authors job is added which:
- checks out the full Git history;
- runs
make update-authorsat the top level; this updates the.mailmapfile and thelal*/AUTHORSfiles, then checks that they are the same as in the Git history. If names are missing, the job fails and the user is asked to runmake update-authorsthemselves and commit the results to the repository.
Closes #613 (closed)
API Changes and Justification
Backwards Compatible Changes
-
This change does not modify any class/function/struct/type definitions in a public C header file or any Python class/function definitions -
This change adds new classes/functions/structs/types to a public C header file or Python module
Backwards Incompatible Changes
-
This change modifies an existing class/function/struct/type definition in a public C header file or Python module -
This change removes an existing class/function/struct/type from a public C header file or Python module
Review Status
cc @adam-mercer for approval. This will mean at least one CI job will try to download the full LALSuite Git history per merge request. When I've been testing this there appears to be minimal performance impact (the lint:authors jobs takes ~5 minutes) but I'm not sure if there are any other performance implications (e.g. disk space).
cc @david-keitel FYI