ci improvements #3688
ci improvements #3688
Conversation
scripts/docker-compose.yml
Outdated
| @@ -23,7 +23,7 @@ services: | |||
|
|
|||
| mysql: | |||
| image: mysql | |||
| command: --default-authentication-plugin=mysql_native_password | |||
| command: --default-authentication-plugin=mysql_native_password --sync_binlog=0 --skip-innodb_doublewrite --innodb-flush-log-at-trx-commit=0 --innodb-flush-method=nosync | |||
There was a problem hiding this comment.
can you add next to this line comment, explaining rationale behind these parameters?
|
What is still to be done for this PR? |
|
Find options for oracle, mssql |
|
Not sure about using ramfs - we use too many instances |
|
@maximelkin Another useful improvement would be to migrate from Travis to CircleCI, btw, since Travis has rather frustrating limits on how often jobs are fired, and in general its future doesn't look particularly bright: https://www.reddit.com/r/devops/comments/at3oyq/it_looks_like_ibera_is_gutting_travis_ci_just_a/ Not sure how difficult such migration would be, but I don't think we are using anything particularly fancy out of Travis features. |
|
@ksatirli Can you take a quick expert glance on our existing Travis config (including maximelkin's improvements in this PR) and assess how difficult would it be to do same things with CircleCI? |
|
here only database tuning options, so It shouldn't affect travisci -> circleci migration |
|
Yeah, I would hope CircleCI also supports passing DB options |
|
So, disabling durability on databases not affected test performance (222 seconds as usual) |
|
@maximelkin Could be that Travis does that by default for CI DBs, which makes sense. I would still keep these changes somewhere around, because there is no guarantee CircleCI does the same thing, we would need to measure again; and TBH I wouldn't mind having these commands in config explicitly. |
|
@kibertoad no, because we running databases via docker-compose |
|
Ah, I see |
Has there been problems with travis so far? I don't see why couldn't we have both running at the same time and see fi Circle CI suits us any better. So far I have been pretty happy with tarvis though (after changing to docker setup). Being able to run tests also in windows would be great though. |
|
@elhigu That's a very good point, we should do that! |
maximelkin
force-pushed
the
ci_configuration
branch
from
1963afd
to
34b4751
Compare
|
Coverage decreased because of switch from node 8 to node 12, should we temporary reduce it? |
|
@maximelkin Wonder why version switch would affect coverage. Any particular reason why switch was needed prior to (incoming) dropping of Node 8 support? |
|
@maximelkin Was it because of DefinitelyTyped/DefinitelyTyped#42275? update: nvm, unrelated |
|
@kibertoad + @maximelkin : It looks like the oracle tests are only running for node 8. So, that probably explains why the coverage dropped. |
|
@briandamaged That was intentional, though, to speed up execution, I think. |
|
Right. I'm just saying that it would also cause the coverage to drop since the Oracle code is not being tested. |
Wait |
|
@maximelkin : By default, Travis-CI currently uses the |
|
Ok, I got this |
|
TODO: exclude tests dir from coverage |
|
@maximelkin What's the end result of this improvement? Did it speed up tests? |
About ~30 seconds for slowest run from batch |
|
pulling oracle image is slowest part |
| @@ -96,6 +96,7 @@ | |||
| "mysql": "^2.18.1", | |||
| "mysql2": "^2.1.0", | |||
| "nyc": "^15.0.0", | |||
| "oracledb": "^4.2.0", | |||
There was a problem hiding this comment.
Considering that testing Oracle is the slowest step, do we want to run it on all Node versions?
There was a problem hiding this comment.
We could add an additional fast test that doesn't pull oracle, but I think its better to have more complete tests than fast ones. In either way it will take long to all test setups to finnish
There was a problem hiding this comment.
Yes, because in other case we can miss some breaking changes from node for oracledb driver code
No description provided.