I think Todd's suggestion may be the most practical. I'm a little reluctant purely because it would be easy for someone to accidentally disable the tests, e.g. by renaming a script. But probably we can live with that.
On Fri, Apr 26, 2019 at 6:02 AM Quanlong Huang <[email protected]> wrote: > It's ok. The job succeeds as expected now :) > > Thanks! > > On Fri, Apr 26, 2019 at 11:49 AM Todd Lipcon <[email protected]> wrote: > > > Perhaps simplest is to just check for the existence of that script, and > if > > it doesn't exist, 'exit 0' from the job, so it doesn't get marked failed? > > > > On Thu, Apr 25, 2019 at 8:40 PM Tim Armstrong <[email protected]> > > wrote: > > > > > I'm sorry about that - I should have thought about the 2.x branch! I > > rolled > > > back the config change for now and will come up with a plan to skip the > > > tests on 2.x. > > > > > > On Thu, Apr 25, 2019 at 6:24 PM Quanlong Huang < > [email protected]> > > > wrote: > > > > > > > Sorry to be late. Can we skip the ubuntu-16.04-dockerised-tests job > for > > > > branch 2.x or add an option to disable it? Just hit a failure due to > > > this: > > > > https://jenkins.impala.io/job/gerrit-verify-dryrun/4064/ > > > > > https://jenkins.impala.io/job/ubuntu-16.04-dockerised-tests/72/console > > > > > > > > File ./bin/jenkins/dockerized-impala-bootstrap-and-test.sh is not > found > > > in > > > > branch 2.x so it will finally fail. > > > > > > > > Thanks, > > > > Quanlong > > > > > > > > On Thu, Apr 25, 2019 at 2:37 AM Tim Armstrong < > [email protected] > > > > > > > wrote: > > > > > > > > > I tested it here: > > > > > https://jenkins.impala.io/job/parallel-all-tests-tarmstrong/ and > it > > > > works > > > > > fine, so I made the corresponding change in precommit at > > > > > > > > > > > > > > > > > > > > https://jenkins.impala.io/job/parallel-all-tests/jobConfigHistory/showDiffFiles?timestamp1=2019-01-18_01-08-25×tamp2=2019-04-24_18-35-23 > > > > > > > > > > Let me know if you see any issues. > > > > > > > > > > On Mon, Apr 22, 2019 at 2:19 PM Lars Volker <[email protected]> > wrote: > > > > > > > > > > > +1 for turning it on > > > > > > > > > > > > On Mon, Apr 22, 2019 at 2:14 PM Tim Armstrong < > > > [email protected] > > > > > > > > > > > wrote: > > > > > > > > > > > > > It's been stable for a while now, with the exception of > hitting a > > > > flaky > > > > > > > test that is also flaky on the non-dockerised minicluster > > > > > (IMPALA-8124) - > > > > > > > https://jenkins.impala.io/job/ubuntu-16.04-dockerised-tests/ > > > > > > > > > > > > > > Are there any objections to me modifying parallel-all-tests and > > > > > therefore > > > > > > > precommit to run this job? I'll wait a couple of days for lazy > > > > > consensus > > > > > > > then go ahead. > > > > > > > > > > > > > > Thanks, > > > > > > > Tim > > > > > > > > > > > > > > On Fri, Apr 5, 2019 at 3:03 PM Lars Volker <[email protected]> > > > wrote: > > > > > > > > > > > > > > > +1, thanks for working on this! > > > > > > > > > > > > > > > > On Fri, Apr 5, 2019 at 11:18 AM Jim Apple < > [email protected]> > > > > > wrote: > > > > > > > > > > > > > > > > > I'm in favor. Given the importance of remote reads, I would > > > even > > > > be > > > > > > in > > > > > > > > > favor of these if it DID extend the critical path. > > > > > > > > > > > > > > > > > > On Fri, Apr 5, 2019 at 10:41 AM Tim Armstrong < > > > > > > [email protected] > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > This is really about testing the dockerised minicluster, > > but > > > > > gives > > > > > > us > > > > > > > > > > coverage of remote read code paths for free, and more > > people > > > > care > > > > > > > about > > > > > > > > > > that right now. > > > > > > > > > > > > > > > > > > > > I got the core end-to-end tests passing locally as part > of > > > > > > > > > > https://issues.apache.org/jira/browse/IMPALA-7995. That > > > change > > > > > is > > > > > > up > > > > > > > > for > > > > > > > > > > review here https://gerrit.cloudera.org/c/12639/. The > next > > > > step > > > > > is > > > > > > > to > > > > > > > > > get > > > > > > > > > > a > > > > > > > > > > Jenkins job running, which I've been working on. > > > > > > > > > > > > > > > > > > > > I'd like to run it regularly so we can catch any > > regressions. > > > > > > > Initially > > > > > > > > > > I'll just have it email me when it fails, but after it's > > > stable > > > > > > for a > > > > > > > > > week > > > > > > > > > > or two I'd like to make it part of the regular set of > jobs. > > > > > > > > > > > > > > > > > > > > My preference is to run it as part of the precommit jobs, > > in > > > > > > parallel > > > > > > > > to > > > > > > > > > > the Ubuntu 16.04 tests. It should not extend the critical > > > path > > > > of > > > > > > > > > precommit > > > > > > > > > > because it only runs the end-to-end tests. We could > > > > alternatively > > > > > > run > > > > > > > > it > > > > > > > > > as > > > > > > > > > > a scheduled post-commit job, but that tends to create > > > > additional > > > > > > work > > > > > > > > > when > > > > > > > > > > it breaks. > > > > > > > > > > > > > > > > > > > > What do people think? > > > > > > > > > > > > > > > > > > > > - Tim > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Todd Lipcon > > Software Engineer, Cloudera > > >
