The CIN validator is an open source, volunteer built tool that allows users to validate CIN census data year round via the command line, or using the browser based front end (URL HERE). It also provides a framework which other validation tools can easily be built on top of.
The functions are documented using sphinx format so that a docs website can be auto-generated if need be. Also, there is an increased use of python type-hints as a form of intrinsic documentation. This does not apply to test functions as they neither receive nor return data, in the strict sense. More extensive documentation can be found here: https://data-to-insight.github.io/CIN-validator/
This repo can be opened and run in a codespaces instance or cloned locally using git clone https://github.com/data-to-insight/CIN-validator.git
If it is cloned locally, use pre-commit install
to install the pre-commit hooks.
python -m cin_validator test
python -m cin_validator list
python -m cin_validator run <path to test data>
-To run rules on the sample data and explore the output of the CLI:
python -m cin_validator run path/to/your/cin/validator/CIN-validator/fake_data/fake_CIN_data.xml
python -m cin_validator run <path to test data> -e "<ERROR_ID as string>"
python -m cin_validator xmltocsv <path to test data>
python get_uk_holidays.py
in the command line. This fetches the latest values of bank holidays into cin_validator\england_holidates.py
(don't edit this file directly) for the rules that need them. Remember to convert \ to / if you are using a unix operating system.cin2023_24
. Do not copy over rules that haven't changed.del_list
array in the current year's init file. Do not delete the rules manually. -r
or --ruleset
flag to specify the name of the rule folder that you wish to run. Otherwise, feel free to update the defaults of the commands so that they point to the new year's folder instead. For example, change cin2022_23
to cin2023_24
. This part is a guide on how to update the frontend so that it reflects the changes that have been done in the backend.
dist
folder completely.pyproject.toml
file. (there is a section below to help you choose the new number.)poetry install
(installs project dependencies) and then poetry shell
(ensures project runs in controlled environment) in the command line. You might have already done this when updating the rules.poetry python -m cin_validator test
in the command line.poetry build
in the command line. You will see that this creates a new dist
folder.release
by navigating to the release page from the right hand control bar on the repo homepage (click on Releases
then draft new release
in the top right hand corner)v
before the version number which you put in the pyproject.toml
file. For example, if you filled in version = "0.1.3"
then on Github, write v0.1.3
as your release tag.generate release notes
at the top right of the main text box. Commit messages of all changes made since the last release will appear in the text box..whl
file from the dist folder in this repo, go to the public\bin\dist
location in the frontend repo, delete the previous cin...whl
file in it and add this one.Actions
tab on Github when your pull request is merged to the frontend.When changes are rules updates (add/delete/modify) or bug fixes, only the last part of the version number should be updated (e.g v0.1.9
becomes v0.1.10
).
The middle number is only updated when new features have been added (the changes enable user functionality that was not previously available).
Finally, the first part of the version number is changed when breaking changes are present (new version of tool is incompatible with previous version e.g when functions in the api, rpc_main.py
, change.)
Read more about semantic versioning here.