-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade core dependencies to 5.0 #225
base: itwinjs-v5
Are you sure you want to change the base?
Conversation
# Conflicts: # pnpm-lock.yaml
@iTwin/transformation-service @iTwin/itwinjs-core-transformer are the performance tests in rawInserts.ts actually run and the results evaluated, and if so is it necessary for them to apply changesets like they currently do? I'd prefer not to introduce a public API for applying changesets to a standalone iModel as that concept is nonsensical.
|
These numbers are collected and visualized in a powerBi report. As for how often they're looked at, I couldn't say. How else can we apply changesets? The only way I could think would be to create a new iModel on the hub each time the test is run and clean it up afterwards? Is that what you were picturing as well? |
Why is imodel-transformer measuring time required to apply changesets? That's totally outside its purview. |
I'm sort of guessing here, but I suppose its to show a comparison between 3 things (in order of fastest to slowest): I think "applying changeset" and "insert" serve to show how much time is added by using the transformer. Perhaps "applying changeset" is unnecessary and we could just use the "insert" to achieve that. I don't know of another reason for the applying changesets test. |
That was my understanding too.
That'd be my preference. |
Removed it |
Unclear what's wrong with extract-api.js. It spit out csv files but no .api.md files. Seems like it must be finding an older version of node or tsc, but if so I can't tell from where.
|
|
Im guessing those are both caused by the semver checks we do in transformer and dev versions tripping it up. Would you like this PR merged soon? My concern is that multiple teams seems to be using this package (not sure to what extent), and we should probably bump the major version of transformer if we're increasing our peer to be minimum 5.0. |
Could you explain? The failures don't seem semver-related to me. The first one looks like a change in behavior (possible regression) in the core packages.
/s/probably/definitely, that's the point of this PR - to upgrade imodel-transformer to use iTwin.js 5.0 as part of its own major version update. Are other changes planned for this package in either the 4.x or 5.x timeline? |
The first failing test checks 'inITwinJSVersionWithExactCodeFeature', this check may be the problem. I could be wrong. The second failing test goes through this code path I believe: https://github.com/iTwin/imodel-transformer/blob/main/packages/transformer/src/IModelTransformer.ts#L908-L920 Luckily we could probably remove these semver checks with the update to 5.0.
There is a currently active PR #172 that i have been working on alongside Julija from transformation-services team. I'd prefer to get that in before updating to 5.x in master. Any opinions on potentially having this PR target a v5 branch as opposed to main? I suppose we could also consider creating a 4.x branch instead and having this go to master. |
I have no opinions, whatever works for this repo. |
@DanRod1999 can you take a look at what may be going on when you get a chance? I was reproducing locally, maybe worth mentioning that changing ONLY @itwin/build-tools to 4.10.3 from 5.0.0-dev.34 seemed to resolve the issue. |
…oft extractor api
…n microsoft extractor api" This reverts commit b1b612e.
@nick4598 @DanRod1999 @ColinKerr or @MichaelSwigerAtBentley please review and merge once satisfied. |
@@ -3536,7 +3536,7 @@ describe("IModelTransformerHub", () => { | |||
rootSubject: { name: masterIModelName }, | |||
}); | |||
// eslint-disable-next-line deprecation/deprecation | |||
masterSeedDb.nativeDb.setITwinId(iTwinId); // workaround for "ContextId was not properly setup in the checkpoint" issue | |||
// masterSeedDb.nativeDb.setITwinId(iTwinId); // workaround for "ContextId was not properly setup in the checkpoint" issue |
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.
is this workaround no longer needed, and are we just keeping these here for future reference?
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.
I frankly have no idea, insufficient information provided in comment.
CI checks are not running on this PR any more because target branch was changed. Maybe some integration tests would fail?
iTwin/itwinjs-core#7512 makes the internal APIs
IModelDb.nativeDb
andIModelHost.platform
inaccessible outside of the core-backend package.