softwerkskammer / Agora

Die Software für die Plattform der Softwerkskammer
Other
55 stars 59 forks source link

vagrant: test suite fails #745

Closed draptik closed 10 years ago

draptik commented 10 years ago

Problem: Test suite (npm test) for current trunk (2014-07-08 f2ddd4d) passes on my host system (Arch Linux), but fails with Vagrant.

Vagrant version: 1.6.3

Here's the relevant part of the failing test:

Running "mocha_istanbul:test" (mocha_istanbul) task
>> Warning: mocha.opts exists, but overwriting with options
No config file found (at least provide a config/winston-config.json) with winston configuration

  ․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․
  ․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․
  ․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․
  ․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․
  ․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․
  ․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․
  ․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․
  ․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․
  ․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․
  ․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․

  948 passing (30s)
  2 failing

  1) Activities Service returns an activity and enhances it with its group and visitors:
     Error: timeout of 5000ms exceeded
      at null.<anonymous> (/vagrant/node_modules/mocha/lib/runnable.js:139:19)
      at Timer.listOnTimeout [as ontimeout] (timers.js:110:15)

  2) Groups application group page displays an existing group and membercount if nobody is logged in:
     Error: timeout of 5000ms exceeded
      at null.<anonymous> (/vagrant/node_modules/mocha/lib/runnable.js:139:19)
      at Timer.listOnTimeout [as ontimeout] (timers.js:110:15)

I haven't looked at the test code, because the test passes on my host machine.

Since the error mentioned a timeout problem, I increased the memory and cpus of the vagrant machine (Vagrantfile):

  config.vm.provider "virtualbox" do |vb|
    vb.customize ["modifyvm", :id, "--memory", "4086"]
    vb.customize ["modifyvm", :id, "--cpus", "4"]
  end

This did not solve the problem (test suite fails with the same message as above).

Am I doing anything wrong? Do other people have this problem?

Thankful for any pointers

Patrick

draptik commented 10 years ago

Just in case it helps:the 2 failing tests are:

test/activities/activitiesService_test.js:

it('returns an activity and enhances it with its group and visitors', function (done) {
    var member1 = new Member({id: 'memberId1', nickname: 'participant1', email: 'a@b.c'});
    var member2 = new Member({id: 'memberId2', nickname: 'participant2', email: 'a@b.c'});
    var owner = new Member({id: 'ownerId', nickname: 'owner', email: 'a@b.c'});
    sinon.stub(activitystore, 'getActivity', function (activityId, callback) { callback(null, emptyActivity); });
    sinon.stub(memberstore, 'getMembersForIds', function (ids, callback) {
      callback(null, [ member1, member2 ]);
    });
    sinon.stub(memberstore, 'getMemberForId', function (id, callback) {
      callback(null, owner);
    });
    sinon.stub(groupstore, 'getGroup', function (groupname, callback) {
      if (groupname === 'groupname') {
        return callback(null, group);
      }
      return callback(null, null);
    });

    activitiesService.getActivityWithGroupAndParticipants('urlOfTheActivity', function (err, activity) {
      expect(activity, 'Activity').to.exist();
      expect(activity.group, 'Group').to.equal(group);
      expect(activity.participants.length).to.equal(2);
      expect(activity.participants, 'Participants').to.contain(member1);
      expect(activity.participants, 'Participants').to.contain(member2);
      expect(activity.ownerNickname, 'Owner').to.equal('owner');
      done(err);
    });
  });

and test/groups/groups_test.js:

it('displays an existing group and membercount if nobody is logged in', function (done) {
      request(createApp())
        .get('/GroupA')
        .expect(200)
        .expect('Content-Type', /text\/html/)
        .expect(/<title>Gruppe A/)
        .expect(/Dies ist Gruppe A\./)
        .expect(/Themengruppe/)
        .expect(/Mitglieder:/)
        .expect(/Diese Gruppe hat&nbsp;2 Mitglieder\./, done);
    });
leider commented 10 years ago

Hi Patrick,

ich schalte mal um auf Deutsch, weil ich vermute, dass du dessen mächtig bist. Falls nicht, sorry.

Zum Thema vagrant: Ist mir ein unbekanntes Phänomen, da ich üblicherweise selbst nicht unter vagrant entwickle, sondern auf meinem "echten Blech".

Du schreibst, dass das ganze im Host läuft, aber im Guest nicht. - Vermutungen: a) Dein Rechner ist zu langsam. b) Dein Vagrant ist anders als dein Linux

Fragen: Ist das bei Dir 100% reproduzierbar?

Zu den Sourcen: die brauchst Du nicht hier einstellen, die sind sowieso da. :)

draptik commented 10 years ago

a) "Rechner zu langsam": Eher nicht. Ich habe der Vagrant VirtualBox mittlerweile 12GB RAM von !6GB gegeben b) "Dein Vagrant ist anders als dein Linux" Ja. Und? Sollte das einen Unterschied machen? Das Linux in der Vagrant Maschine ist doch nicht abhaengig von dem Linux des Host Systems, oder habe ich da was falsch verstanden?

"Fragen:Ist das bei Dir 100% reproduzierbar?" Das ist bei mir 100% reproduzierbar.

NicoleRauch commented 10 years ago

Hi Patrick,

das klingt ja echt merkwürdig - wir haben das ab und zu, dass der eine oder andere Test hängenbleibt, aber meistens, weil irgendwas zu langsam ist (üblicherweise auf dem Travis CI-Server), und das ist dann im Normalfall auch nicht reproduzierbar.

Ich kann mir grad auch nichts vorstellen, was diese beiden Tests von anderen unterscheiden sollte, so dass der Hänger irgendwie erklärbar wäre...

Hast Du eine Chance, mal in die beiden Tests hineinzudebuggen, um genauer festzustellen, wo sie hängenbleiben?

Viele Grüße Nicole

leider commented 10 years ago

Ich kann es reproduzieren.

draptik commented 10 years ago

sollte Andreas nichts finden, werde ich mich mal ins Debuggen stuerzen.

Hab ich eh noch nie gemacht: Asynchronen javascript-Code, mit gemockten Daten. Wird mal Zeit. Nen Link parat fuer diese Art des Debuggings (tooling, best-practice)?

draptik commented 10 years ago

nur interessehalber: Warum ist dieser Bug Report/diese Konversation nicht oeffentlich sichtbar? Unter https://github.com/softwerkskammer/Agora/issues?labels=bug&state=open finde ich diesen Thread nicht.

leider commented 10 years ago

Sollte er aber sein.

Am 10.07.2014 um 00:45 schrieb Patrick Drechsler notifications@github.com:

nur interessehalber: Warum ist dieser Bug Report/diese Konversation nicht oeffentlich sichtbar?

— Reply to this email directly or view it on GitHub.

leider commented 10 years ago

Bittesehr. Ich komme die Tage nicht dazu.

Am 09.07.2014 um 22:25 schrieb Patrick Drechsler notifications@github.com:

sollte Andreas nichts finden, werde ich mich mal ins Debuggen stuerzen.

Hab ich eh noch nie gemacht: Asynchronen javascript-Code, mit gemockten Daten. Wird mal Zeit. Nen Link parat fuer diese Art des Debuggings (tooling, best-practice)?

— Reply to this email directly or view it on GitHub.

NicoleRauch commented 10 years ago

Man sieht den Issue deswegen nicht, weil er nicht als Bug markiert ist :-) Wenn Du die Einschränkung, dass er als Bug gelabelt sein soll, entfernst, kannst Du den Issue sehen.

leider commented 10 years ago

So, jetzt habe ich ein bissel Luft, um mehr als einsilbig zu schreiben.

Tooling für diesen speziellen Fall habe ich auch nicht parat. Falls Du im Zuge dieses Bughuntings damit Erfahrungen sammelst, wäre ich sehr dankbar, wenn Du das Wissen mit uns teilst.

draptik commented 10 years ago

Hab jetzt mal ein paar Stuendchen gesucht, aber bin der Loesung nicht wirklich naeher gekommen.

Da die Test Suite auf dem Host System fehlerfrei durchlaeuft, habe ich Fehler im Code erstmal ausgeschlossen.

Da das aktuelle Verzeichnis auf dem Host-System mit dem Vagrant Client geshared wird, habe ich das funktionierende node-modules Verzeichnis in node_modules.working_host umbenannt. Davor die aktuell installierten Node-Pakete in eine Datei geschrieben (npm list > npm_list_host.txt).

Danach unter Vagrant npm install && npm list > npm_list_vagrant.txt && npm test ausgefuehrt.

Immer noch derselbe Fehler. Das Verzeichnis node-modules Verzeichnis in node_modules.vagrant umbenannt.

Danach habe ich die installierten Nodepaketversionen verglichen (diff -u npm_list_host.txt npm_list_vagrant.txt). Hierbei ist mir nichts ins Auge gestochen.

Auch der Vergleich der Verzeichnisse node_modules.working_host mit node_modules.vagrant hat keine offensichtlichen Unterschiede gezeigt.

Dann habe ich die NodeJs Version in Vagrant aktualisiert (via PPA; von Version v0.10.15 auf v0.10.29). node_modules Verzeichnis geloescht. npm install && npm test.

Immer noch derselbe Fehler.

Hab leider keine Ideen mehr. Man koennte noch versuchen, die Ubuntu Version auf 14.04 hochzuziehen, aber ich bezweifle, dass es daran liegt.

Gibt es denn Leute, bei denen die Test Suite mit Vagrant funktioniert?

draptik commented 10 years ago

@NicoleRauch "Man sieht den Issue deswegen nicht, weil er nicht als Bug markiert ist :-) Wenn Du die Einschränkung, dass er als Bug gelabelt sein soll, entfernst, kannst Du den Issue sehen." Mmh... Da habe ich wohl Tomaten auf den Augen, Ich finde das Wort "Bug" nicht im UserInterface... Ist auch nicht so wild :-)

leider commented 10 years ago

Ist bei den Labels, die man einem Issue vergeben kann.

draptik commented 10 years ago

Hab noch eine Stellschraube gefunden, die minimal-invasiv ist (siehe pull-request): Einfach den Timeout der Tests um 1sec erhoehen (Default: 2sec, aktuell: 5sec, neuer Wert: 6sec).