[OpenStack-Infra] Too much optimizations in project-config jobs ; (

Paul Belanger pabelanger at redhat.com
Tue Dec 1 17:25:40 UTC 2015


On Tue, Dec 01, 2015 at 04:33:56PM +0000, Jeremy Stanley wrote:
> On 2015-12-01 09:22:38 +0100 (+0100), Andreas Jaeger wrote:
> > We recently merged changes to limit the running of jobs on
> > project-config to run only when a job is needed.
> > 
> > But now we have a change [1] to data/* which is not covered by any
> > of the existing jobs and thus no job is run.
> > 
> > What shall we do? Always run one of the existing jobs? Extend a
> > job to cover all files? Revert the last change for this?
> [...]
> 
> I'm not really a fan of skipping jobs based on which files are
> changed since it can lead to gaps in effective test coverage (or not
> running any jobs at all in cases like this one). It's too easy to
> get wrong, or to fall out of step with reorganizations/refactors
> within the repository being tested. I'm in favor of running all
> project-config jobs on all project-config changes, or at worst only
> applying this workaround to jobs which take a really long time to
> complete (e.g., nodepool integration testing).
> -- 
> Jeremy Stanley
> 
I would agree that is the downside, but in general I think project-config is
looking good.

Are you recommending we roll back the current changes and run all gates for each
commit?
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra



More information about the OpenStack-Infra mailing list