On 25 Jun 2015 1:24 am, "Jeremy Stanley" <[email protected]> wrote: > > 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).
Yes, I skipped over that. I'm going to leave the driver file where it is, so that will take a diff and pass the new lines from the diff to the new lint. > > 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. This is why I'm going to leave the driver logic where it is. I just want the parsing and policy consolidated. > > 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. I don't think it's a matter of acceptance but rather race proof. Otherwise concurrent changes to other requirements would make this job fail. -rob
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
