Open Stack

On 2015-06-24 16:03:18 +1200 (+1200), Robert Collins wrote:
[...]
> We also have a strict/nonstrict mode which appears to be the same to me.

The requirements validation check compares old vs. new versions of
files so that it can only enforce matching on lines which are being
changed. The non-strict parsing mode is used on the old copy of the
file so that validation errors there don't make the file permanently
unfixable (e.g. when the validation job is added to a project with a
preexisting nonconforming requirements list).

> So - I'd like to do two things here.
> 
> Firstly, I want to move all the linting code into
> openstack/requirements, so we don't have two different parsers that
> *can* vary in what they can handle. That seems mechanical.
[...]

Not entirely a mechanical translation. The script is preinstalled on
job workers now so that it can run in a job for any project, and is
already designed as an integration test (using zuul-cloner to obtain
the global requirements list). However, if we move the script into
openstack/requirements we'll need to rework the job itself to know
where to get the script, which probably means moving zuul-cloner
calls into the job definition (or keeping a stub of the original
script preinstalled on our workers to handle the cloning logic for
us). It's entirely solvable though, agreed.

> I propose the following to reconcile:
>  - I'll add a lint command to openstack/requirements
>  - it will check for \n
>  - it will accept the set that openstack/requirements accepts in each
> of non-strict and strict mode
>  - anything that parses will be checked against global-requirements
> for equivalence.
[...]

There is still a regression here. Our current linting checks only
requirements that are being changed, not the entire list. There are
projects which elect to edit the proposed requirements updates to
defer or even indefinitely skip updates to some entries. We can
declare that this behavior is unacceptable going forward, but
otherwise we'll need to preserve the current line-by-line/diff
comparison mechanism in the new linter.
-- 
Jeremy Stanley