At Drupalcon Munich @moshe weitzman told me that Travis CI was not able to run all of Drush tests in one go. There seems to be a way of grouping them so they can be run in chunks instead of all together.

I first need to read about Travis CI and possibly clone Drush to my Github account in order to start debugging, but all suggestions and tips are welcome.

Comments

juampynr’s picture

I have started by forking Drush repository at Github and configuring it at Travis. It is running now and I can see that it is already taking more than 10 minutes to complete and is still running. From what I understood by @moshe weitzman, it will get to a point in which it will simply stop.

http://travis-ci.org/#!/juampy72/drush

juampynr’s picture

Actually it did finish after 55 minutes but with an error. See http://travis-ci.org/#!/juampy72/drush/jobs/2271101

moshe weitzman’s picture

That test run completed in 7 minutes, not 55. Hope you can keep working on this :)

juampynr’s picture

Sure! Is still in my head. I will give it another go.

clemens.tolboom’s picture

Version: » 8.x-6.x-dev

The current status value for https://travis-ci.org/drush-ops/drush is 12 days old.

I'm not sure what that means. Is something wrong regarding travis integration or ... ?

Do all tests pass locally as suggested in #1841324-8: Requiring php 5.3.5 for Drush is premature ? Do I run tests wrong #2010042: Use composer to configure the test environment (as I still have sqlite failures).

It would be great to have Travis running again to compare with.

moshe weitzman’s picture

Status: Active » Fixed

Travis seems to finishing just fine so this issue is closed.

We are not testing on sqlite so I can't say if test suite passes there. Please continue to post test fails for sqlite.

Travis tests against a Github repo and we only push there once in a while. It would be good if someone would setup a mirror service from git.drupal.org to https://github.com/drush-ops/drush or we should just move to github for version control.

helmo’s picture

Moving to github seems like a bad idea...

A cronjob to sync (daily) would be nice to bridge the gap though.

Woudn't something like this do the trick: "git pull origin && git push github --mirror"

clemens.tolboom’s picture

A good doc (not completely similar to our problem) is on https://www.chiliproject.org/projects/chiliproject/wiki/HowTo_mirror_you...

But it needs a key, cron, server and some time :-/

helmo’s picture

clemens.tolboom’s picture

Status: Fixed » Active

Set to active to let @moshe weitzman ask for a mirror :)

helmo’s picture

I'll do this in my github fork for the time being.

Travis results: https://travis-ci.org/helmo/drush

I'm working on a simple script that updates my github fork, while keeping the modified .travis.yml

git co 7.x-5.x
git pull --rebase origin 7.x-5.x
git push --force github 7.x-5.x
git co 8.x-6.x
git pull --rebase origin 8.x-6.x
git push --force github 8.x-6.x

First spin-off: #2029493: testBackendMethodPost fails on php 5.4

PS: As the official repo would not need a modified .travis.yml the mirroring process would be simpler.

moshe weitzman’s picture

I've pretty much decided to move the Drush project off drupal.org and onto Github. In short, I really want pull requests and I want automatic unit testing of those requests. drupal.org is on a path to get us those features shortly before the earth boils.

I think I'll shut down the git and issue tracking on drupal.org right after I get Drush6 out the door.

More info about the 2 features that make this move compelling for me:

  1. https://github.com/blog/712-pull-requests-2-0
  2. http://about.travis-ci.org/blog/announcing-pull-request-support/
greg.1.anderson’s picture

Yeah, I am in favor. I was reluctant before, but github is nicer to use. Drush does not need to tie in to pm-updatecode like Drupal modules do, so the downsides are for the most part social.

helmo’s picture

While the (testable)pull requests are tempting I'd hate to lose the d.o issue queue. Sure it's not perfect, but neither is Github.

clemens.tolboom’s picture

I'm not in favor for changing to github as we loose many features.

I feel similar as chx blogged "Why the github PR workflow is far inferior to the current one" http://www.drupal4hu.com/node/371

The very first step is broken here: you fork the repository. At this very moment you are off the main community and noone knows what's going on. You hack but hack alone. Currently one can review the 'entity system' issues in one central place where discussion and code is happening (github separates issues from pull requests). This coherent, single, participatory, inclusive system is missing. We do not want people going off and working separately, making their work visible only when they think it's ready. Not to mention that github doesn't have priorities, components and anything besides tags.

On d.o I have my dashboard to track all Drupal related stuff. It is possible to move an issue from one project to another.

A github pull request is a single persons effort and not a collaboration in contrast to d.o. I've read https://github.com/blog/712-pull-requests-2-0 but afaik I cannot change the code of another persons PR.

I don't want to loose my d.o dashboard :-/

But have PR tested is of course great :)

helmo’s picture

New meta issue: #2039507: [meta] Testing SQLite support

For reference, my current sync script looks like:

#!/bin/bash

set -x

cd /home/helmo/src/drupal/drush_autotest/drush

git fetch --all
git co 7.x-5.x
git pull --rebase origin 7.x-5.x
git push --force github 7.x-5.x
git co 8.x-6.x
git pull --rebase origin 8.x-6.x
git push --force github 8.x-6.x

git co 8.x-6.x-sqlite
git pull --rebase origin 8.x-6.x
git push --force github 8.x-6.x-sqlite

git co 8.x-6.x-cleanup
git pull --rebase origin 8.x-6.x
git push --force github 8.x-6.x-cleanup
git co 8.x-6.x-test54
git pull --rebase origin 8.x-6.x
git push --force github 8.x-6.x-test54
cd -
helmo’s picture

Cool, only one 5.4 specific issue left: #2030311: testUnknownOptions fails on PHP 5.4

And one regression: #2039465: Travis test failure

moshe weitzman’s picture

Status: Active » Fixed

Back to fixed. We are moving to Github.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.