Open Stack

On 25 Jun 2015 1:24 am, "Jeremy Stanley" <fungi at yuggoth.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150625/8a6612a3/attachment.html>