[openstack-dev] [requirements] converging the openstack-infra/project-config and openstack/requirements requirements checks
robertc at robertcollins.net
Wed Jun 24 18:23:16 UTC 2015
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
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev