Follow up edits and formatting after recent PRs (#5941)
* Follow up edit and formatting pass * Add trailing return
This commit is contained in:
Greg Van Liew
GitHub
Родитель
eee5079026
Коммит
74c1942a25
|
|
@ -59,14 +59,14 @@ Context name | True when
|
|||
`editorHasSelection` | Text is selected in the editor.
|
||||
`editorHasMultipleSelections` | Multiple regions of text are selected (multiple cursors).
|
||||
`editorReadonly` | The editor is read only.
|
||||
`editorLangId` | True when the editor's associated [language ID](/docs/languages/identifiers) matches. Example: `"editorLangId == typescript"`.
|
||||
`editorLangId` | True when the editor's associated [language ID](/docs/languages/identifiers) matches.<br>Example: `"editorLangId == typescript"`.
|
||||
`isInDiffEditor` | The active editor is a difference editor.
|
||||
`isInEmbeddedEditor` | True when the focus is inside an embedded editor.
|
||||
**Operating system contexts** |
|
||||
`isLinux` | True when the OS is Linux
|
||||
`isMac` | True when the OS is macOS
|
||||
`isWindows` | True when the OS is Windows
|
||||
`isWeb` | True when accessing the editor from the Web
|
||||
`isLinux` | True when the OS is Linux.
|
||||
`isMac` | True when the OS is macOS.
|
||||
`isWindows` | True when the OS is Windows.
|
||||
`isWeb` | True when accessing the editor from the Web.
|
||||
**List contexts** |
|
||||
`listFocus` | A list has focus.
|
||||
`listSupportsMultiselect` | A list supports multi select.
|
||||
|
|
@ -77,15 +77,15 @@ Context name | True when
|
|||
`inSnippetMode` | The editor is in snippet mode.
|
||||
`inQuickOpen` | The Quick Open dropdown has focus.
|
||||
**Resource contexts** |
|
||||
`resourceScheme` | True when the resource Uri scheme matches. Example: `"resourceScheme == file"`
|
||||
`resourceFilename` | True when the Explorer or editor filename matches. Example: `"resourceFilename == gulpfile.js"`
|
||||
`resourceExtname` | True when the Explorer or editor filename extension matches. Example: `"resourceExtname == .js"`
|
||||
`resourceDirname` | True when the Explorer or editor's resource absolute folder path matches. Example: `"resourceDirname == /users/alice/project/src"`
|
||||
`resourcePath` | True when the Explorer or editor's resource absolute path matches. Example: `"resourcePath == /users/alice/project/gulpfile.js"`
|
||||
`resourceLangId` | True when the Explorer or editor title [language ID](/docs/languages/identifiers) matches. Example: `"resourceLangId == markdown"`
|
||||
`isFileSystemResource` | True when the Explorer or editor file is a file system resource that can be handled from a file system provider
|
||||
`resourceSet` | True when an Explorer or editor file is set
|
||||
`resource` | The full Uri of the Explorer or editor file
|
||||
`resourceScheme` | True when the resource Uri scheme matches.<br>Example: `"resourceScheme == file"`
|
||||
`resourceFilename` | True when the Explorer or editor filename matches.<br>Example: `"resourceFilename == gulpfile.js"`
|
||||
`resourceExtname` | True when the Explorer or editor filename extension matches.<br>Example: `"resourceExtname == .js"`
|
||||
`resourceDirname` | True when the Explorer or editor's resource absolute folder path matches.<br>Example: `"resourceDirname == /users/alice/project/src"`
|
||||
`resourcePath` | True when the Explorer or editor's resource absolute path matches.<br>Example: `"resourcePath == /users/alice/project/gulpfile.js"`
|
||||
`resourceLangId` | True when the Explorer or editor title [language ID](/docs/languages/identifiers) matches.<br>Example: `"resourceLangId == markdown"`
|
||||
`isFileSystemResource` | True when the Explorer or editor file is a file system resource that can be handled from a file system provider.
|
||||
`resourceSet` | True when an Explorer or editor file is set.
|
||||
`resource` | The full Uri of the Explorer or editor file.
|
||||
**Explorer contexts** |
|
||||
`explorerViewletVisible` | True if Explorer view is visible.
|
||||
`explorerViewletFocus` | True if Explorer view has keyboard focus.
|
||||
|
|
@ -104,10 +104,10 @@ Context name | True when
|
|||
`parameterHintsVisible` | Parameter hints are visible (controlled by `editor.parameterHints.enabled` setting).
|
||||
`parameterHintsMultipleSignatures` | Multiple parameter hints are displayed.
|
||||
**Debugger contexts** |
|
||||
`debuggersAvailable` | An appropriate debugger extension is available
|
||||
`debuggersAvailable` | An appropriate debugger extension is available.
|
||||
`inDebugMode` | A debug session is running.
|
||||
`debugState` | Active debugger state. Possible values are `inactive`, `initializing`, `stopped`, `running`.
|
||||
`debugType` | True when debug type matches. Example: `"debugType == 'node'"`.
|
||||
`debugState` | Active debugger state.<br>Possible values are `inactive`, `initializing`, `stopped`, `running`.
|
||||
`debugType` | True when debug type matches.<br>Example: `"debugType == 'node'"`.
|
||||
`inDebugRepl` | Focus is in the Debug Console REPL.
|
||||
**Integrated terminal contexts** |
|
||||
`terminalFocus` | An integrated terminal has focus.
|
||||
|
|
@ -115,10 +115,10 @@ Context name | True when
|
|||
**Timeline view contexts** |
|
||||
`timelineFollowActiveEditor` | True if the Timeline view is following the active editor.
|
||||
**Timeline view item contexts** |
|
||||
`timelineItem` | True when the timeline item's context value matches. Example: `"timelineItem =~ /git:file:commit\\b/"`.
|
||||
`timelineItem` | True when the timeline item's context value matches.<br>Example: `"timelineItem =~ /git:file:commit\\b/"`.
|
||||
**Extension contexts** |
|
||||
`extension` | True when the extension's ID matches. Example: `"extension == eamodio.gitlens"`.
|
||||
`extensionStatus` | True when the extension is installed. Example: `"extensionStatus == installed"`.
|
||||
`extension` | True when the extension's ID matches.<br>Example: `"extension == eamodio.gitlens"`.
|
||||
`extensionStatus` | True when the extension is installed.<br>Example: `"extensionStatus == installed"`.
|
||||
`extensionHasConfiguration` | True if the extension has configuration.
|
||||
**Global UI contexts** |
|
||||
`notificationFocus` | Notification has keyboard focus.
|
||||
|
|
@ -133,9 +133,9 @@ Context name | True when
|
|||
`workbenchState` | Can be `empty`, `folder` (1 folder), or `workspace`.
|
||||
`workspaceFolderCount` | Count of workspace folders.
|
||||
`replaceActive` | Search view Replace text box is open.
|
||||
`view` | For `view/title` and `view/item/context`, the view to display the command in. Example: `"view == myViewsExplorerID"`.
|
||||
`viewItem` | For `view/item/context`, the `contextValue` from the tree item. Example: `"viewItem == someContextValue"`.
|
||||
`webviewId` | For `webview/context`, the webview ID to display the command in. Example: `"webviewId == catCoding"`.
|
||||
`view` | For `view/title` and `view/item/context`, the view to display the command in.<br>Example: `"view == myViewsExplorerID"`.
|
||||
`viewItem` | For `view/item/context`, the `contextValue` from the tree item.<br>Example: `"viewItem == someContextValue"`.
|
||||
`webviewId` | For `webview/context`, the webview ID to display the command in.<br>Example: `"webviewId == catCoding"`.
|
||||
`isFullscreen` | True when window is in fullscreen.
|
||||
`focusedView` | The identifier of the currently focused view.
|
||||
`canNavigateBack` | True if it is possible to navigate back.
|
||||
|
|
@ -147,7 +147,7 @@ Context name | True when
|
|||
`editorIsOpen` | True if one editor is open.
|
||||
`groupEditorsCount` | Number of editors in a group.
|
||||
`activeEditorGroupEmpty` | True if the active editor group has no editors.
|
||||
`activeEditorGroupIndex` | A number starting from `1` reflecting the position of an editor group in the editor grid. The group with index `1` will be the first in the top-left corner.
|
||||
`activeEditorGroupIndex` | A number starting from `1` reflecting the position of an editor group in the editor grid.<br>The group with index `1` will be the first in the top-left corner.
|
||||
`activeEditorGroupLast` | Will be `true` for the last editor group in the editor grid.
|
||||
`multipleEditorGroups` | True when multiple editor groups are present.
|
||||
`activeEditor` | The identifier of the active editor in a group.
|
||||
|
|
@ -160,14 +160,14 @@ Context name | True when
|
|||
|
||||
>**Note**: You can use any user or workspace setting that evaluates to a boolean here with the prefix `"config."`.
|
||||
|
||||
## Visible/Focused view when clause context
|
||||
## Visible/focused view when clause context
|
||||
|
||||
You can have a when clause that checks if a specific [View](/api/ux-guidelines/views) is visible or focused.
|
||||
|
||||
Context name | True when
|
||||
------------ | ------------
|
||||
`view.${viewId}.visible` | True when specific view is visible. Example: `"view.workbench.explorer.fileView.visible"`
|
||||
focusedView | True when specific view is focused. Example: `"focusedView == 'workbench.explorer.fileView'"`
|
||||
`view.${viewId}.visible` | True when specific view is visible.<br>Example: `"view.workbench.explorer.fileView.visible"`
|
||||
focusedView | True when specific view is focused.<br>Example: `"focusedView == 'workbench.explorer.fileView'"`
|
||||
|
||||
View identifiers:
|
||||
|
||||
|
|
@ -197,9 +197,9 @@ You can have a when clause that checks if a specific [View Container](/api/ux-gu
|
|||
|
||||
Context name | True when
|
||||
------------ | ------------
|
||||
activeViewlet | True when view container is visible in the sidebar. Example: `"activeViewlet == 'workbench.view.explorer'"`
|
||||
activePanel | True when view container is visible in the panel. Example: `"activePanel == 'workbench.panel.output'"`
|
||||
activeAuxiliary | True when view container is visible in the secondary sidebar. Example: `"activeAuxiliary == 'workbench.view.debug'"`
|
||||
activeViewlet | True when view container is visible in the sidebar.<br>Example: `"activeViewlet == 'workbench.view.explorer'"`
|
||||
activePanel | True when view container is visible in the panel.<br>Example: `"activePanel == 'workbench.panel.output'"`
|
||||
activeAuxiliary | True when view container is visible in the secondary sidebar.<br>Example: `"activeAuxiliary == 'workbench.view.debug'"`
|
||||
|
||||
View container identifiers:
|
||||
|
||||
|
|
|
|||
|
|
@ -1003,7 +1003,7 @@
|
|||
<priority>0.8</priority>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://code.visualstudio.com/remote/advancedcontainers/avoid-extension-reinstalls</loc>
|
||||
<loc>https://code.visualstudio.com/remote/advancedcontainers/sharing-git-credentials</loc>
|
||||
<changefreq>weekly</changefreq>
|
||||
<priority>0.8</priority>
|
||||
</url>
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ Visual Studio Code and the Python extension provide a great editor for data scie
|
|||
|
||||
|
||||
|
||||
9. To manage your environment from VS Code's integrated terminal, open it up with (`kb(workbench.action.terminal.toggleTerminal)`). If your environment is not activated, you can do so as you would in your terminal (i.e. `conda activate myenv`).
|
||||
9. To manage your environment from VS Code's integrated terminal, open it up with (`kb(workbench.action.terminal.toggleTerminal)`). If your environment is not activated, you can do so as you would in your terminal (`conda activate myenv`).
|
||||
|
||||
## Prepare the data
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ This lets VS Code provide a **local-quality development experience** including f
|
|||
|
||||
## Getting started
|
||||
|
||||
**Note**: You can learn how to get up-and-running quickly with dev containers in the introductory [dev container tutorial](/docs/devcontainers/tutorial.md).
|
||||
**Note**: You can learn how to get up-and-running quickly with dev containers in the introductory [Dev Containers tutorial](/docs/devcontainers/tutorial.md).
|
||||
|
||||
### System requirements
|
||||
|
||||
|
|
@ -256,7 +256,7 @@ You can use any image, Dockerfile, or set of Docker Compose files as a starting
|
|||
}
|
||||
```
|
||||
|
||||
> **Note:** Additional configuration will already be added to the container based on what's in the base image. For example, we add the `streetsidesoftware.code-spell-checker` extension above, and the container will also include `"dbaeumer.vscode-eslint"` as [that's part of `mcr.microsoft.com/devcontainers/typescript-node`](https://github.com/devcontainers/images/blob/main/src/javascript-node/.devcontainer/devcontainer.json#L27). This happens automatically when pre-building using devcontainer.json, which you may read more about in the [pre-build section](#pre-building-dev-container-images).
|
||||
> **Note:** Additional configuration will already be added to the container based on what's in the base image. For example, we add the `streetsidesoftware.code-spell-checker` extension above, and the container will also include `"dbaeumer.vscode-eslint"` as [that's part of `mcr.microsoft.com/devcontainers/typescript-node`](https://github.com/devcontainers/images/blob/main/src/javascript-node/.devcontainer/devcontainer.json#L27). This happens automatically when pre-building using `devcontainer.json`, which you may read more about in the [pre-build section](#prebuilding-dev-container-images).
|
||||
|
||||
Selecting the **Dev Containers: Add Dev Container Configuration Files...** command from the Command Palette (`kbstyle(F1)`) will add the needed files to your project as a starting point, which you can further customize for your needs. The command lets you pick a pre-defined container configuration from a list based on your folder's contents, reuse an existing Dockerfile, or reuse an existing Docker Compose file.
|
||||
|
||||
|
|
@ -301,7 +301,7 @@ A Feature is a self contained entity in a folder with at least a `devcontainer-f
|
|||
| +-- (other files)
|
||||
```
|
||||
|
||||
Check out the [feature/starter](https://github.com/devcontainers/feature-starter) repo for instructions on using the dev container CLI to publish your own public or private Features.
|
||||
Check out the [feature/starter](https://github.com/devcontainers/feature-starter) repository for instructions on using the dev container CLI to publish your own public or private Features.
|
||||
|
||||
### Features specification and distribution
|
||||
|
||||
|
|
@ -313,19 +313,19 @@ We recommend pre-building images with the tools you need rather than creating an
|
|||
|
||||
Even better - pre-built images can contain Dev Container metadata so when you reference an image, settings will be pulled across automatically.
|
||||
|
||||
We recommend using the [Dev Container CLI](/docs/devcontainers/devcontainer-cli.md) (or other spec supporting utilities like the [GitHub Action](https://github.com/marketplace/actions/devcontainers-ci)) to pre-build your images since it is kept in sync with the Dev Containers extension's latest capabilities - including [dev container Features](#dev-container-features). Once you've built your image, you can push it to a container registry (like the [Azure Container Registry](https://learn.microsoft.com/azure/container-registry/container-registry-get-started-docker-cli?tabs=azure-cli), [GitHub Container Registry](https://docs.github.com/packages/working-with-a-github-packages-registry/working-with-the-container-registry#pushing-container-images), or [Docker Hub](https://docs.docker.com/engine/reference/commandline/push)) and reference it directly.
|
||||
We recommend using the [Dev Container CLI](/docs/devcontainers/devcontainer-cli.md) (or other [specification](https://containers.dev) supporting utilities like the [GitHub Action](https://github.com/marketplace/actions/devcontainers-ci)) to pre-build your images since it is kept in sync with the Dev Containers extension's latest capabilities - including [dev container Features](#dev-container-features). Once you've built your image, you can push it to a container registry (like the [Azure Container Registry](https://learn.microsoft.com/azure/container-registry/container-registry-get-started-docker-cli?tabs=azure-cli), [GitHub Container Registry](https://docs.github.com/packages/working-with-a-github-packages-registry/working-with-the-container-registry#pushing-container-images), or [Docker Hub](https://docs.docker.com/engine/reference/commandline/push)) and reference it directly.
|
||||
|
||||
You can use the GitHub Action in the [devcontainers/ci](https://github.com/devcontainers/ci) repo to help you reuse dev containers in your workflows.
|
||||
You can use the GitHub Action in the [devcontainers/ci](https://github.com/devcontainers/ci) repository to help you reuse dev containers in your workflows.
|
||||
|
||||
See the [dev container CLI article on pre-building images](/docs/devcontainers/devcontainer-cli.md#prebuilding) for more information.
|
||||
Go to the [dev container CLI article on pre-building images](/docs/devcontainers/devcontainer-cli.md#prebuilding) for more information.
|
||||
|
||||
### Inheriting metadata
|
||||
|
||||
You can include Dev Container configuration and Feature metadata in prebuilt images via [image labels](https://docs.docker.com/config/labels-custom-metadata/). This makes the image self-contained since these settings are automatically picked up when the image is referenced - whether directly, in a `FROM` in a referenced Dockerfile, or in a Docker Compose file. This helps prevent your Dev Container config and image contents from getting out of sync, and allows you to push updates of the same configuration to multiple repositories through a simple image reference.
|
||||
|
||||
This metadata label is **automatically added** when you pre-build using the [Dev Container CLI](./devcontainer-cli.md) (or other spec supporting utilities like the [GitHub Action](https://github.com/marketplace/actions/devcontainers-ci) or [Azure DevOps task](https://marketplace.visualstudio.com/items?itemName=devcontainers.ci)) and includes settings from devcontainer.json and any referenced Dev Container Features.
|
||||
This metadata label is **automatically added** when you pre-build using the [Dev Container CLI](/docs/devcontainers/devcontainer-cli.md) (or other [specification](https://containers.dev) supporting utilities like the [GitHub Action](https://github.com/marketplace/actions/devcontainers-ci) or [Azure DevOps task](https://marketplace.visualstudio.com/items?itemName=devcontainers.ci)) and includes settings from `devcontainer.json` and any referenced Dev Container Features.
|
||||
|
||||
This allows you to have a separate **more complex** devcontainer.json you use to pre-build your image, and then a dramatically **simplified one** in one or more repositories. The contents of the image will be merged with this simplified devcontainer.json content at the time you create the container (see the [the spec](https://containers.dev/implementors/spec/#merge-logic) for info on merge logic). But at its simplest, you can just reference the image directly in devcontainer.json for the settings to take effect:
|
||||
This allows you to have a separate **more complex** `devcontainer.json` you use to pre-build your image, and then a dramatically **simplified one** in one or more repositories. The contents of the image will be merged with this simplified `devcontainer.json` content at the time you create the container (go to [the spec](https://containers.dev/implementors/spec/#merge-logic) for information on merge logic). But at its simplest, you can just reference the image directly in `devcontainer.json` for the settings to take effect:
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -333,7 +333,7 @@ This allows you to have a separate **more complex** devcontainer.json you use to
|
|||
}
|
||||
```
|
||||
|
||||
Note that you can also opt to you can opt to manually add metadata to an image label instead. These proprerties will be picked up even if you didn't use the Dev Container CLI to build (and can be updated by the CLI even if you do). For example, consider this Dockerfile snippet:
|
||||
Note that you can also opt to manually add metadata to an image label instead. These properties will be picked up even if you didn't use the Dev Container CLI to build (and can be updated by the CLI even if you do). For example, consider this Dockerfile snippet:
|
||||
|
||||
```Dockerfile
|
||||
LABEL devcontainer.metadata='[{ \
|
||||
|
|
@ -347,7 +347,7 @@ LABEL devcontainer.metadata='[{ \
|
|||
|
||||
Occasionally you may run into a situation where you are using a Docker named volume that you want to inspect or make changes in. You can use VS Code to work with these contents without creating or modifying `devcontainer.json` file by selecting the **Dev Containers: Explore a Volume in a Dev Container...** from the Command Palette (`kbstyle(F1)`).
|
||||
|
||||
You can also inspect your volumes in the Remote Explorer. Make sure you have Containers selected in the dropdown, then you'll notice a **Dev Volumes** section. You can right-click on a volume to inspect its creation information, like when the volume was created, what repo was cloned into it, and the mountpoint. You can also explore it in a dev container.
|
||||
You can also inspect your volumes in the Remote Explorer. Make sure you have Containers selected in the dropdown, then you'll notice a **Dev Volumes** section. You can right-click on a volume to inspect its creation information, like when the volume was created, what repository was cloned into it, and the mountpoint. You can also explore it in a dev container.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ For this example, if you'd like to install the [Code Spell Checker extension](ht
|
|||
}
|
||||
```
|
||||
|
||||
> **Note:** Additional configuration will already be added to the container based on what's in the base image. For example, we add the `streetsidesoftware.code-spell-checker` extension above, and the container will also include `"dbaeumer.vscode-eslint"` as [that's part of `mcr.microsoft.com/devcontainers/typescript-node`](https://github.com/devcontainers/images/blob/main/src/javascript-node/.devcontainer/devcontainer.json#L27). This happens automatically when pre-building using devcontainer.json, which you may read more about in the [pre-build section](./containers.md#pre-building-dev-container-images).
|
||||
> **Note:** Additional configuration will already be added to the container based on what's in the base image. For example, we add the `streetsidesoftware.code-spell-checker` extension above, and the container will also include `"dbaeumer.vscode-eslint"` as [that's part of `mcr.microsoft.com/devcontainers/typescript-node`](https://github.com/devcontainers/images/blob/main/src/javascript-node/.devcontainer/devcontainer.json#L27). This happens automatically when pre-building using devcontainer.json, which you may read more about in the [pre-build section](/docs/devcontainers/containers.md#prebuilding-dev-container-images).
|
||||
|
||||
With the above `devcontainer.json`, your dev container is functional, and you can connect to and start developing within it. Try it out with the **Dev Containers: Reopen in Container** command:
|
||||
|
||||
|
|
|
|||
|
|
@ -259,12 +259,12 @@ See the [Advanced container configuration](/remote/advancedcontainers/overview.m
|
|||
* [Changing or removing the default source code mount](/remote/advancedcontainers/change-default-source-mount.md)
|
||||
* [Improving container disk performance](/remote/advancedcontainers/improve-performance.md)
|
||||
* [Adding a non-root user to your dev container](/remote/advancedcontainers/add-nonroot-user.md)
|
||||
* [Avoiding extension reinstalls on container rebuild](/remote/advancedcontainers/avoid-extension-reinstalls.md)
|
||||
* [Setting the project name for Docker Compose](/remote/advancedcontainers/set-docker-compose-project-name.md)
|
||||
* [Using Docker or Kubernetes from inside a container](/remote/advancedcontainers/use-docker-kubernetes.md)
|
||||
* [Connecting to multiple containers at once](/remote/advancedcontainers/connect-multiple-containers.md)
|
||||
* [Developing inside a container on a remote Docker Machine or SSH host](/remote/advancedcontainers/develop-remote-host.md)
|
||||
* [Reducing Dockerfile build warnings](/remote/advancedcontainers/reduce-docker-warnings.md)
|
||||
* [Sharing git credentials with your container](/remote/advancedcontainers/sharing-git-credentials.md)
|
||||
|
||||
## Extension tips
|
||||
|
||||
|
|
|
|||
|
|
@ -118,7 +118,7 @@ In the example we just explored, the project has a `.devcontainer` folder with a
|
|||
|
||||
First, your image is built from the supplied Dockerfile or image name, which would be `mcr.microsoft.com/devcontainers/javascript-node:0-18` in this example. Then a container is created and started using some of the settings in the `devcontainer.json`. Finally your Visual Studio Code environment is installed and configured again according to settings in the `devcontainer.json`. For example, the dev container in this example installs the `streetsidesoftware.code-spell-checker` extension.
|
||||
|
||||
> **Note:** Additional configuration will already be added to the container based on what's in the base image. For example, we see the `streetsidesoftware.code-spell-checker` extension above, and the container will also include `"dbaeumer.vscode-eslint"` as [that's part of `mcr.microsoft.com/devcontainers/typescript-node`](https://github.com/devcontainers/images/blob/main/src/javascript-node/.devcontainer/devcontainer.json#L27). This happens automatically when pre-building using devcontainer.json, which you may read more about in the [pre-build section](./containers.md#pre-building-dev-container-images).
|
||||
> **Note:** Additional configuration will already be added to the container based on what's in the base image. For example, we see the `streetsidesoftware.code-spell-checker` extension above, and the container will also include `"dbaeumer.vscode-eslint"` as [that's part of `mcr.microsoft.com/devcontainers/typescript-node`](https://github.com/devcontainers/images/blob/main/src/javascript-node/.devcontainer/devcontainer.json#L27). This happens automatically when pre-building using devcontainer.json, which you may read more about in the [pre-build section](/docs/devcontainers/containers.md#prebuilding-dev-container-images).
|
||||
|
||||
Once all of this is done, your local copy of Visual Studio Code connects to the Visual Studio Code Server running inside of your new dev container.
|
||||
|
||||
|
|
@ -134,10 +134,10 @@ The `devcontainer.json` is basically a config file that determines how your dev
|
|||
"name": "Node.js",
|
||||
|
||||
// Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile
|
||||
"image": "mcr.microsoft.com/devcontainers/javascript-node:0-18",
|
||||
"image": "mcr.microsoft.com/devcontainers/javascript-node:0-18",
|
||||
|
||||
// Features to add to the dev container. More info: https://containers.dev/features.
|
||||
// "features": {},
|
||||
// "features": {},
|
||||
|
||||
"customizations": {
|
||||
"vscode": {
|
||||
|
|
@ -150,12 +150,12 @@ The `devcontainer.json` is basically a config file that determines how your dev
|
|||
|
||||
// "forwardPorts": [3000],
|
||||
|
||||
"portsAttributes": {
|
||||
"9000": {
|
||||
"label": "Hello Remote World",
|
||||
"onAutoForward": "notify"
|
||||
}
|
||||
},
|
||||
"portsAttributes": {
|
||||
"9000": {
|
||||
"label": "Hello Remote World",
|
||||
"onAutoForward": "notify"
|
||||
}
|
||||
},
|
||||
|
||||
"postCreateCommand": "yarn install",
|
||||
|
||||
|
|
@ -167,9 +167,9 @@ The above example is extracted from the `vscode-remote-try-node` repo we used in
|
|||
|
||||
| Option | Description |
|
||||
|---|---|
|
||||
| `image` | The name of an image in a container registry ([DockerHub](https://hub.docker.com/), [GitHub Container Registry](https://docs.github.com/packages/guides/about-github-container-registry), [Azure Container Registry](https://azure.microsoft.com/services/container-registry/)) VS Code should use to create the dev container. <br> |
|
||||
| `image` | The name of an image in a container registry ([Docker Hub](https://hub.docker.com/), [GitHub Container Registry](https://docs.github.com/packages/guides/about-github-container-registry), [Azure Container Registry](https://azure.microsoft.com/services/container-registry/)) VS Code should use to create the dev container. <br> |
|
||||
| `dockerfile` | Rather than referencing an `image`, you may instead use the `dockerfile` property, which is the relative path to a `Dockerfile` that you want to use as your image. |
|
||||
| `features` | An object of [Dev Container Feature](./containers.md#dev-container-features) IDs and related options to be added. |
|
||||
| `features` | An object of [Dev Container Feature](/docs/devcontainers/containers.md#dev-container-features) IDs and related options to be added. |
|
||||
| `customizations` | Configure tool-specific properties, like `settings` and `extensions` properties for VS Code. |
|
||||
| `settings` | Adds default `settings.json` values into a container/machine specific settings file, such as `"terminal.integrated.defaultProfile.linux": "bash"`. |
|
||||
| `extensions` | An array of extension IDs that specify the extensions that should be installed inside the container when it is created. |
|
||||
|
|
|
|||
|
|
@ -309,7 +309,7 @@ If there are conflicting values, such as `editor.selectionBackground` in the exa
|
|||
|
||||
### Note about multiple language specific settings
|
||||
|
||||
If you are using [multiple language-specific settings](#multiple-language-specific-editor-settings), be aware that language-specific settings are merged and precedence is set based on the full language string (for example `"[typescript][javascript]"`) and not the individual language IDs (`typescript` and `javascript`). This means that for example, a `"[typescript][javascript]"` workspace setting will not override a `"[javascript]"` user setting.
|
||||
If you are using [multiple language-specific settings](#multiple-languagespecific-editor-settings), be aware that language-specific settings are merged and precedence is set based on the full language string (for example `"[typescript][javascript]"`) and not the individual language IDs (`typescript` and `javascript`). This means that for example, a `"[typescript][javascript]"` workspace setting will not override a `"[javascript]"` user setting.
|
||||
|
||||
## Settings and security
|
||||
|
||||
|
|
|
|||
|
|
@ -47,9 +47,10 @@ A **conda environment** is a Python environment that's managed using the `conda`
|
|||
If Visual Studio Code doesn't locate your interpreter automatically, you can [manually specify an interpreter](#manually-specify-an-interpreter).
|
||||
|
||||
If an interpreter hasn't been specified, then the Python extension automatically selects the interpreter with the highest version in the following priority order:
|
||||
|
||||
1. Virtual environments located directly under the workspace folder.
|
||||
2. Virtual environments related to the workspace but stored globally. For example, [Pipenv](https://pypi.org/project/pipenv/) or [Poetry](https://python-poetry.org/) environments that are localed outside of the workspace folder
|
||||
3. Globally installed interpreters. FOr example, the ones found in `/usr/local/bin`, `C:\\python27`, `C:\\python38`, etc.
|
||||
2. Virtual environments related to the workspace but stored globally. For example, [Pipenv](https://pypi.org/project/pipenv/) or [Poetry](https://python-poetry.org/) environments that are located outside of the workspace folder.
|
||||
3. Globally installed interpreters. For example, the ones found in `/usr/local/bin`, `C:\\python27`, `C:\\python38`, etc.
|
||||
|
||||
> **Note**: The interpreter selected may differ from what `python` refers to in your terminal.
|
||||
|
||||
|
|
|
|||
|
|
@ -714,7 +714,7 @@ Finally, you may need to clone the repository again for these settings to take e
|
|||
|
||||
### Sharing Git credentials between Windows and WSL
|
||||
|
||||
If you use HTTPS to clone your repositories and **have a [credential helper configured](https://help.github.com/articles/caching-your-github-password-in-git) in Windows**, you can share this with WSL so that passwords you enter are persisted on both sides. (Note that this does not apply to using SSH keys.)
|
||||
If you use HTTPS to clone your repositories and **have a [credential helper configured](https://docs.github.com/get-started/getting-started-with-git/caching-your-github-credentials-in-git) in Windows**, you can share this with WSL so that passwords you enter are persisted on both sides. (Note that this does not apply to using SSH keys.)
|
||||
|
||||
Just follow these steps:
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ If you are behind a firewall that needs to allow specific domains used by VS Cod
|
|||
* `bingsettingssearch.trafficmanager.net` - In-product settings search
|
||||
* `vscode.search.windows.net` - In-product settings search
|
||||
* `raw.githubusercontent.com` - GitHub repository raw file access
|
||||
* `vsmarketplacebadge.apphb.com` - Visual Studio Marketplace badge service
|
||||
* `vsmarketplacebadges.dev` - Visual Studio Marketplace badge service
|
||||
* `az764295.vo.msecnd.net` - Visual Studio Code download CDN
|
||||
* `download.visualstudio.microsoft.com` - Visual Studio download server, provides dependencies for some VS Code extensions (C++, C#)
|
||||
* `vscode-sync.trafficmanager.net` - Visual Studio Code Settings Sync service
|
||||
|
|
|
|||
|
|
@ -3,9 +3,9 @@ Order: 15
|
|||
Area: advancedcontainers
|
||||
TOCTitle: Sharing git credentials
|
||||
PageTitle: Sharing git credentials
|
||||
ContentId:
|
||||
ContentId: 4627daab-1bc2-4e3b-ba81-cd9319ec1230
|
||||
MetaDescription: Sharing git credentials
|
||||
DateApproved: 1/4/2023
|
||||
DateApproved: 12/7/2022
|
||||
---
|
||||
|
||||
# Sharing Git credentials with your container
|
||||
|
|
@ -23,7 +23,7 @@ The extension will automatically copy your local `.gitconfig` file into the cont
|
|||
|
||||
## Using a credential helper
|
||||
|
||||
If you use HTTPS to clone your repositories and **have a [credential helper configured](https://help.github.com/articles/caching-your-github-password-in-git) in your local OS, no further setup is required.** Credentials you've entered locally will be reused in the container and vice versa.
|
||||
If you use HTTPS to clone your repositories and **have a [credential helper configured](https://docs.github.com/get-started/getting-started-with-git/caching-your-github-credentials-in-git) in your local OS, no further setup is required.** Credentials you've entered locally will be reused in the container and vice versa.
|
||||
|
||||
## Using SSH keys
|
||||
|
||||
|
|
@ -72,7 +72,7 @@ fi
|
|||
|
||||
## Sharing GPG Keys
|
||||
|
||||
If you want to [GPG](https://www.gnupg.org/) sign your commits, you can share your local keys with your container as well. You can find out about signing using a GPG key in [GitHub's documentation](https://help.github.com/github/authenticating-to-github/managing-commit-signature-verification).
|
||||
If you want to [GPG](https://www.gnupg.org/) sign your commits, you can share your local keys with your container as well. You can find out about signing using a GPG key in [GitHub's documentation](https://docs.github.com/authentication/managing-commit-signature-verification).
|
||||
|
||||
If you do not have GPG set up, you can configure it for your platform:
|
||||
|
||||
|
|
@ -101,4 +101,4 @@ RUN sudo apt-get update && sudo apt-get install gnupg2 -y
|
|||
|
||||
The next time the container starts, your GPG keys should be accessible inside the container as well.
|
||||
|
||||
> **Note:** If you used `gpg` previously in the container, you may need to run **Dev Containers: Rebuild Container** for the update to take effect.
|
||||
> **Note:** If you used `gpg` previously in the container, you may need to run **Dev Containers: Rebuild Container** for the update to take effect.
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче