[Spike] Fix CI Failures (dashdb) #76
Comments
37 tasks
30 tasks
|
A new dashdb VM was set up. The only failing test in the Jenkins CI build is: dashdb imported features ( in loopback-connector-dashdb/test/imported.test.js ) Here is the actual test case code : |
|
What's confusing is when , on my laptop, I set my environment variables to the same values as the updated variables in Jenkins (including IP to new dashdb VM), I get different failures : Do I need to update the version of loopback-datasource-juggler or something? |
|
I set CI=true and then re-ran (thanks for the tip @b-admike ) Only 2 errors now: |
|
Tried interacting directly with db2 warehouse database using the If I define a table where ID column is primary key it is possible to insert rows with same ID value with no error. I tried this with a plain db2 (non-db2-warehouse) database, with same table definitions, and plain db2 doesn't allow duplicate ID values (which is good). For db2 warehouse it seems that in March 2018 there was some kind of change with regards to the enforcement of primary key constraints. http://www-01.ibm.com/support/docview.wss?uid=swg22010509 Using a create table definition with the |
|
In /Users/dremond/Documents/PRs_LoopBack/connector-dashdb-failures/loopback-connector-dashdb/test/init.js connector capabilities for testing are set in : global.connectorCapabilities = { The original failing test it checks for a connector capability named I decided to try adding this property into global.connectorCapabilities to see what would happen.
global.connectorCapabilities = {
global.connectorCapabilities = {
|
|
What we need to find out still is if all the tests were working beforehand with an older version of dashdb (db2 warehouse). (The original VM with dashdb no longer boots, so it is not possible to view the old dashdb version). Currently with the dash db we just installed on a new VM for our Jenkins CI , the test is failing. @b-admike had a few tips moving forward: this is where we build the primary key constraints for both dashdb/db2 https://github.com/strongloop/loopback-ibmdb/blob/055def01d116e9fbdb794d8046af66c934550762/lib/ibmdb.js#L826-L842 one way we deal with db version functionality changes https://github.com/strongloop/loopback-connector-mongodb/blob/2ba8cc77089a1573280568c85a75b4723ff4544a/deps/juggler-v3/test.js#L32-L49 this is where flags are defined for juggler common tests https://github.com/strongloop/loopback-connector-dashdb/blob/master/test/init.js#L40-L43 We may need to have loopback-dashdb-connector override in so that it can add the And we may only need to do this in our test suite for certain versions of dashdb and not others. |
|
Thank you @emonddr for capturing the information on GitHub. Since the scope of this task is to fix the failing CI build, I am proposing to skip the problematic test for now (by setting I think we should spend the remaining time on investigating the second failing test, |
|
I found someone to speak to on the DB2 Warehouse team. She gave me some commands to view or set a specific setting related the issue we ran into. To show the current value of To set the value to YES: I was able to confirm the setting was indeed turned on: |
|
Latest run of CI job for Node.js 10 shows zero errors: |
This was referenced Jul 17, 2019
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Timeboxed to week and a half
Description/Steps to reproduce
Right now, we have test cases (29) failing for CI runs on master. We need to fix them, so that we have master passing and so that new pull requests do not have to ignore / worry about them.
The text was updated successfully, but these errors were encountered: