Added JS Jasmine tests to Travis CI #9013
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -76,4 +76,20 @@ case $TEST_SUITE in | |
|
|
||
| cd ../../.. | ||
| ;; | ||
| js) | ||
| curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.1/install.sh | bash | ||
| export NVM_DIR="$HOME/.nvm" | ||
| [ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh" # This loads nvm | ||
| nvm install --lts | ||
|
There was a problem hiding this comment. I believe it would be more robust to specify some concrete version, like in https://github.com/BanzaiMan/travis_production_test/blob/9c02aef/.travis.yml#L15, so that we see in environment variable which version we test against There was a problem hiding this comment. I'm not sure if we really need to care about precise versioning, b/c in Oct 2017 we should be ready to use v7 without any issues and necessary updates in code base. Node.js LTS plan is precisely described here - https://github.com/nodejs/LTS There was a problem hiding this comment. If I understood the doc right v7 is not LTS and will not be used in such code. The point is that I don't see any value in dynamic As soon as There was a problem hiding this comment. You are right, v8, not v7. There was a problem hiding this comment. Is it guaranteed that using v6 for tests before, we will not have any issues under v8 when it become LTS? What's BC police? There was a problem hiding this comment. OFC there are BC between major releases, but major becomes LTS after half year and most of the packages get updates during this period, so migration is in most of the cases are seamless. There was a problem hiding this comment. It does not mean all our tests will work without changes. Just answer the simple question - what is the value of NOT specifying a concrete version but using LTS instead? There was a problem hiding this comment. By the way, There was a problem hiding this comment. You are always up to date, don't have to follow releases schedule etc. When new LTS version will be up, your tests will start using it. But to just quit discussion, I'll change it to Docs about
So in our case, we can simply remove this param. There was a problem hiding this comment. Thanks!
Yeah, that's a scary part as to me, as put our builds a bit out of control. |
||
| nvm use --lts | ||
|
|
||
| cp package.json.sample package.json | ||
| cp Gruntfile.js.sample Gruntfile.js | ||
| npm install -g yarn | ||
|
There was a problem hiding this comment. Is it really viable to install There was a problem hiding this comment. Not only There was a problem hiding this comment. Thanks for clarification. |
||
| yarn global add grunt-cli | ||
| yarn | ||
|
|
||
| cp dev/travis/js/config.php app/etc | ||
| php bin/magento setup:static-content:deploy -f | ||
| ;; | ||
| esac | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at https://travis-ci.org/magento/magento2/jobs/215020317 - is there some less verbose mode? Display only failed tests maybe...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No idea, for now I just focuses on make this test running, then we can think about some adjustments / improvements.
PS. I really hate Grunt, so if I don't have to modify this, I will be more than happy to leave it as it is 😉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I didn't use it as well, and didn't google for a solution just in case you know the answer.
It can wait until it become a problem "output is too big" some day (hopefully never).