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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
