Convert flaky API test to unit test (#253863 , #254041)
I maintain my conviction that there is an unrelated run-away API test which steals focus while these tests execute which then leads to these tests failing, since the undo command is sensitive to the current focused editor.
* Add quickPickItemResource API proposal
* Transfer resourceUri from extension host to main thread.
* Make proposed API checks consistent.
* Process resourceUri
* Fix up resourceUri mapping logic
* API proposal
* Transfer toggles from extension host to main thread
* Support Folder icon, refactor label/description derivation.
* Update
* Update API proposal per API review
* Update transfer logic per API changes
* Move toggles to the base input interface
* Handle toggle button type
* Fix up
* Updates
* Propagate checked state, dispose removed toggles.
* Nit
* Expand icons
* Feedback/updates
* Added comments, PR feedback
* Updates
* Revert some change, add typings and unit-tests to converters.
* Add a quick pick test for resourceUri
* Test updates
Single quoted string usage is already enforced everywhere except our tests. Having this inconsistent style can confuse contributors and code generation
Starting with converting over tests in the `extensions` dir
For #271167
This makes it so our built-in extensions can mostly be built using `tsc` on the command line. Previously the extensions were picking up a lot of typing info from the root `node_modules` that meant they weren't truly independent
For #269213
This adds a new eslint rule for `as any` and `<any>({... })`. We'd like to remove almost all of these, however right now the first goal is to prevent them in new code. That's why with this first PR I simply add `eslint-disable` comments for all breaks
Trying to get this change in soon after branching off for release to hopefully minimize disruption during debt week work
`workbench.action.chat.open.blockOnResponse` is flaking in CI. So far,
I cannot reproduce locally so skipping to avoid noise in CI while I
debug.
Since the core logic (i.e. not the test) is only hit if `blockOnResponse`
is set to `true`, leaving it in is low-risk.
Relates #263572.
Relates #263575.
* add `workbench.action.chat.open::waitForComplete`
* s/waitForCompletion/blockOnResponse
* cleanup tests
* remove unused comment
* Apply suggestion from @connor4312
Co-authored-by: Connor Peet <connor@peet.io>
* fixup tests
* don't block test loop on invokeTool
* Revert "don't block test loop on invokeTool"
This reverts commit d8d16dbe79fda2538cdb5bfb743158c6348ecf4b.
* fix tool confirmation test
* attempt to account for the flip of isPendingConfirmation
* [DEBUG] debug CI flake
* register tool so it exists in all test envs
* finish configuring custom tool
* run test in seperate chat windows
* revert debug changes
* remove timeout dep
* fix assertion
* cleaup tests by examining output of command directly
---------
Co-authored-by: Connor Peet <connor@peet.io>
* Remove startup experimentation code and setup splitWelcomeChat view as getting started experience
* Remove experimental visibility check from welcome message in ChatWidget
* cleanup
---------
Co-authored-by: Benjamin Pasero <benjamin.pasero@microsoft.com>
* Start small
* start on new byok api
* Some more api work
* Hook up more of the API
* A single file with no errors yay!
* Some cleanup
* Slow and steady progress
* More code
* Add resolve
* Hate everything
* More progress on rewriting id
* Some error fixing
* Fix null service
* Use claude to fix tests
* Fix tests
* Fix tests
* More test fixing
* Some setup
* Some model picker stuff
* Fix model picker with new BYOK api
* Remove support for contirbuting to mdel picker action bar
* Adjust to allow for user prompting
* Add event
* Fix conflicts
