I agree with the approach of running the tests on supported platforms. In
the past couple of days, there have been multiple issues (IMPALA-7678
<https://issues.apache.org/jira/browse/IMPALA-7678> & IMPALA-7690
<https://issues.apache.org/jira/browse/IMPALA-7690>) due to python2.6
compatibility issues. Additionally, python2.6 might be one of the place
where multiple linux distributions differ. So it probably makes sense to
add another centos-from-scratch or similar, rather than adding ad-hoc tests
to address issues as they come up.
Thanks,
Pooja
On Thu, Sep 27, 2018 at 2:43 PM Philip Zeyliger <phi...@cloudera.com> wrote:
> I think the approach to catch that is to just run the tests on the relevant
> platform. (E.g., with test-with-docker or something to make the Jenkins
> setup less painful.) Looking through some recent commits, I found:
>
> 304e02cf6238a3c1e9537337f802bcf7a92df5db "{}".format(1)
> 9cfa228c2e itertools.count(start=1)
> cf4f314922f13fbf54c6d7300ceaa2229bf5916a shutil.make_archive(); Multiple
> with statements in the same context
> d91bc44021f28a5d113285be9c920bd1a646a9b9 {dict_comprehension}
> ??? a set comprehension; remember fixing it; couldn't find it.
>
> So, it's a mix of both classes, but I don't see recurring things that would
> be easy to catch.
>
> -- Philip
>
>
> On Thu, Sep 27, 2018 at 2:14 PM Tim Armstrong <tarmstr...@cloudera.com>
> wrote:
>
> > Is it worth adding some regexes or similar to the gerrit bot to catch
> > itertools.count() usage? Or do we not expect repeated bugs of this form?
> >
> > On Thu, Sep 27, 2018 at 12:59 PM Tim Armstrong <tarmstr...@cloudera.com>
> > wrote:
> >
> > > I also added it to the pre-review tests. Let me know if you see any
> > issues.
> > >
> > > On Thu, Sep 27, 2018 at 12:33 PM Philip Zeyliger <phi...@cloudera.com>
> > > wrote:
> > >
> > >> Hi folks,
> > >>
> > >> To address IMPALA-6543, there's a new test in parallel-all-tests that
> > >> makes
> > >> sure that any Python scripts use Python2.6-compatible syntax. Note
> that
> > >> this will catch the "try/catch/finally" style of bug, but not the
> > >> "itertools.count(start=1)" kind of bug (python2.7 changed the
> signature
> > of
> > >> itertools.count).
> > >>
> > >> The relevant diff was:
> > >>
> > >> $diff -u /tmp/b /tmp/a
> > >> --- /tmp/b 2018-09-27 12:29:15.000000000 -0700
> > >> +++ /tmp/a 2018-09-27 12:28:58.000000000 -0700
> > >> @@ -23,6 +23,14 @@
> > >> if (restring != null && !restring.equals("SUCCESS")) {
> > >> failed_job_urls.add(result.getAbsoluteUrl())
> > >> }
> > >> +}, Python26Compatibility: {
> > >> + result = build job: 'python26-incompatibility-check', propagate:
> > >> false, parameters:
> > >> + [string(name: 'IMPALA_REPO_URL', value: IMPALA_REPO_URL),
> > >> + string(name: 'IMPALA_REPO_BRANCH', value: IMPALA_REPO_BRANCH)]
> > >> + restring = result.getResult()
> > >> + if (restring != null && !restring.equals("SUCCESS")) {
> > >> + failed_job_urls.add(result.getAbsoluteUrl())
> > >> + }
> > >> }, TidyAndBuildOnlyAndRat: {
> > >> result = build job: 'clang-tidy-ub1604', propagate: false,
> > >> parameters:
> > >> [string(name: 'IMPALA_REPO_URL', value: IMPALA_REPO_URL),
> > >>
> > >> This will show up in your GVO builds. I've tested it, but of course
> let
> > me
> > >> know if you run into any trouble.
> > >>
> > >> Thanks!
> > >>
> > >
> >
>
