<p dir="ltr"><br>
On 25 Jun 2015 1:24 am, "Jeremy Stanley" <<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>> wrote:<br>
><br>
> On 2015-06-24 16:03:18 +1200 (+1200), Robert Collins wrote:<br>
> [...]<br>
> > We also have a strict/nonstrict mode which appears to be the same to me.<br>
><br>
> The requirements validation check compares old vs. new versions of<br>
> files so that it can only enforce matching on lines which are being<br>
> changed. The non-strict parsing mode is used on the old copy of the<br>
> file so that validation errors there don't make the file permanently<br>
> unfixable (e.g. when the validation job is added to a project with a<br>
> preexisting nonconforming requirements list).<br></p>
<p dir="ltr">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.</p>
<p dir="ltr">> > So - I'd like to do two things here.<br>
> ><br>
> > Firstly, I want to move all the linting code into<br>
> > openstack/requirements, so we don't have two different parsers that<br>
> > *can* vary in what they can handle. That seems mechanical.<br>
> [...]<br>
><br>
> Not entirely a mechanical translation. The script is preinstalled on<br>
> job workers now so that it can run in a job for any project, and is<br>
> already designed as an integration test (using zuul-cloner to obtain<br>
> the global requirements list). However, if we move the script into<br>
> openstack/requirements we'll need to rework the job itself to know<br>
> where to get the script, which probably means moving zuul-cloner<br>
> calls into the job definition (or keeping a stub of the original<br>
> script preinstalled on our workers to handle the cloning logic for<br>
> us). It's entirely solvable though, agreed.</p>
<p dir="ltr">This is why I'm going to leave the driver logic where it is. I just want the parsing and policy consolidated.</p>
<p dir="ltr">> > I propose the following to reconcile:<br>
> >  - I'll add a lint command to openstack/requirements<br>
> >  - it will check for \n<br>
> >  - it will accept the set that openstack/requirements accepts in each<br>
> > of non-strict and strict mode<br>
> >  - anything that parses will be checked against global-requirements<br>
> > for equivalence.<br>
> [...]<br>
><br>
> There is still a regression here. Our current linting checks only<br>
> requirements that are being changed, not the entire list. There are<br>
> projects which elect to edit the proposed requirements updates to<br>
> defer or even indefinitely skip updates to some entries. We can<br>
> declare that this behavior is unacceptable going forward, but<br>
> otherwise we'll need to preserve the current line-by-line/diff<br>
> comparison mechanism in the new linter.<br></p>
<p dir="ltr">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.</p>
<p dir="ltr">-rob</p>