Skip to content

Conversation

kumar303
Copy link
Contributor

@kumar303 kumar303 changed the title Show Docker logs again in functional tests [WIP] Show Docker logs again in functional tests Jul 10, 2017
@kumar303
Copy link
Contributor Author

kumar303 commented Jul 10, 2017

Even though the tests mysteriously fixed themselves, I researched this and could see some legitimate causes for failure. It sucks to replace one line of piped bash commands with 200 lines of JS but I think it helps buy us many things:

  • We can see the docker startup logs again which is essential for troubleshooting
  • The UI tests should be faster since they no longer sleep for a minute at startup
  • The UI tests should be more reliable -- sleeping for a minute might not have been enough when Travis was really busy
  • I think some of the missing command failure output will be solved now
  • You can run the UI tests locally (this wasn't so easy before on Mac OS X)
  • Docker gets a compatible log driver by default which is my theory for what was causing the failure (without this fix we were at the mercy of system defaults which could vary between Travis machines)

@kumar303 kumar303 changed the title [WIP] Show Docker logs again in functional tests Show Docker logs again in functional tests Jul 10, 2017
@kumar303 kumar303 requested a review from tofumatt July 10, 2017 22:43
Copy link
Contributor

@tofumatt tofumatt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

r+wc

Thanks a tonne for this. 👍


// TODO: make these configurable when we need to start
// servers for multiple apps.
const appInstance = 'disco';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using process.env.NODE_APP_INSTANCE would be a pretty easy fix here I think and buy us most of that. I think it's already passed to the tests on travis... if not you could easily add it to the env vars.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Heh, I thought so too but passing env vars to commands in .travis.yml is not straight forward. I think it's best to deal with it later. I think we may have to create an amo and a disco package.json script.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah okay, no problem.

}
return new Promise((resolve, reject) => {
childProcess.exec(cmdString, { cwd: root }, (error, stdout, stderr) => {
let gotOutput = false;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally I found gotOutput a bit of an odd variable name to grok at first. Maybe receivedOutput would be better?

@kumar303 kumar303 merged commit 878330c into mozilla:master Jul 11, 2017
@kumar303 kumar303 deleted the fix-travis-iss2704 branch July 11, 2017 14:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Discopane UI tests are returning 1 and causing CI to report failures
2 participants