-
-
Notifications
You must be signed in to change notification settings - Fork 92
Fix Notebook CI failures; pin vscode version #768
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
Fix Notebook CI failures; pin vscode version #768
Conversation
7ffc1c3 to
8e1df44
Compare
third-party-licenses.csv
Outdated
| "immutability-helper@3.1.1","MIT","https://github.com/kolodny/immutability-helper","https://github.com/kolodny/immutability-helper/raw/master/LICENSE","cursorless" | ||
| "jsonc-parser@2.3.1","MIT","https://github.com/microsoft/node-jsonc-parser","https://github.com/microsoft/node-jsonc-parser/raw/master/LICENSE.md","parse-tree" | ||
| "mdast-util-find-and-replace@2.1.0","MIT","https://github.com/syntax-tree/mdast-util-find-and-replace","https://github.com/syntax-tree/mdast-util-find-and-replace/raw/master/license","website" | ||
| "lodash@4.17.21","MIT","https://github.com/lodash/lodash","https://github.com/lodash/lodash/raw/master/LICENSE","cursorless" |
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.
Interesting that this list has changed, despite the affected packages not changing in package.json or yarn.lock.
| "extensionKind": [ | ||
| "workspace" | ||
| "workspace", | ||
| "ui" |
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.
Added this based on user requests. Should help with running in various VSCode contexts, even if command-server might not work there
| "@types/semver": "^7.3.9", | ||
| "@types/sinon": "^10.0.2", | ||
| "@types/vscode": "^1.61.0", | ||
| "@types/vscode": "~1.61.0", |
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.
Pinned for now so that we don't break backwards compatibility
| // FIXME: All these type casts are necessary because we've pinned VSCode | ||
| // version type defs. Can remove them once we are using more recent type defs |
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'm not in love with this stuff, but not sure how to avoid it if we want to maintain backwards compatibility with older VSCode versions
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'm not fully understanding why we can't bump the VSCode type defs, though. Can you walk through it?
Is this a "looking forward" thing, ie. these APIs will eventually be deprecated?
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.
There is a step in the vsce package command that checks whether the minimum VSCode engine version is less than the VSCode type defs version. So if we use the most recent type defs, we will have to bump our VSCode minimum engine, which would force all users to upgrade to the very latest VSCode, which seems a bit aggressive
Maybe there's a way to disable that check?
| const vscodeExecutablePath = await downloadAndUnzipVSCode(); | ||
| // NB: We include the exact version here instead of in `test.yml` so that | ||
| // we don't have to update the branch protection rules every time we bump | ||
| // the legacy VSCode version. |
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.
Hmm, you could set the job name using the matrix, but I guess this works as well.
Alternatively we could have a job that requires test, but seems excessive for what we need.
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.
How would I go about setting the job name using the matrix? I don't see that in the docs 🤔. Do I just refer to {{ matrix.vscode_version }} in the name field of the job? And then I guess I'd use some kind of conditional expression to check whether it's equal to "stable"?
I guess alternately I could keep the version in the matrix as legacy and then put some kind of ternary in an expression when we define the env variable VSCODE_VERSION in test.yml? I didn't see anything bout a ternary either tho.
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'm going to ship this one as is to get CI working again, but feel free to add comments here if you have a better solution
|
|
||
| if (activeTextEditor == null) { | ||
| return; | ||
| if (lt(version, "1.68.0")) { |
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.
Might be overkill, but it might make sense to store this in a constants file. We should likely check lt and also ensure gt from some baseline.
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.
constants makes sense. Not sure bout gt; we get that for free from the VSCode min engine thing above
| ); | ||
|
|
||
| const cellOffset = editorIndex - activeEditorIndex; | ||
| const activeTextEditor = window.activeTextEditor; |
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.
It seems like we do this in many cases, might be interesting to think if there are ways we can add an AOP type filter for various actions.
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.
Sorry not sure I'm following. Fwiw looks like I don't use the active text editor below, so I can remove this null check. It was a holdover from a previous approach. But maybe that's not what you're referring to?
Related to #497
Checklist