Add tasks support to devcontainer.json

[rubensa]

Looks like, currently, only launch configurations are supported inside devcontainer.json.

You can define launch configurations in devcontainer.json like:

{
  "customizations": {
    "vscode": {
      "settings": {
        "launch": {
          "configurations": [
          ]
        },
      }
    }
  }
}

It would be great to have the same but for tasks. Something like:

{
  "customizations": {
    "vscode": {
      "settings": {
        "tasks": [
        ],
      }
    }
  }
}

This way we could have a set of predefined launch and tasks configurations available in the devcontainer (and checked in the git repository, as they are inside the devcontainer.json file) and allow the user to "extend" those configurations locally (by adding them to .vscode folder that might be added to .gitignore).

NOTE: I suppose this should also be added to .code-workspace settings implementation (as, under the hood, looks like devcontainers are using the workspace settings mechanism) and documented in default settings.

[vscodenpa]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 10 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[vscodenpa]

🙂 This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[benzman81]

This would be great, for now, we have to copy our default tasks in all our workspaces :-(

[alexanderilyin]

I feel like it worked already before...

P. S. VSCode: 0 Me: 1

  "customizations": {
    "vscode": {
      "settings": {
          "tasks": {
            "version": "2.0.0",
            "tasks": [
              {
                "label": "echo",
                "type": "shell",
                "command": "echo Hello"
              }
            ]
          },

P. P. S. I found some section in docs (or some info that it might work that way) year ago or so, but yes it took a while.

[chrmarti]

@sandy081 I didn't know this works: "tasks" is shown as unknown configuration setting in the remote settings, but the task is shown in Run Task and correctly runs.

[sandy081]

It is working because tasks are loaded as part of settings.

[chrmarti]

@sandy081 Should it become part of the schema?

[sandy081]

It is not official to support tasks inside settings. Its an implementation detail. To support it officially, you should have a separate tasks section in devContainer.json and create the tasks file in the remote machine, just like settings.json.

[rubensa]

@sandy081 From your answer I suppose that the launch configuration in devcontainer.json is also not supported (just another implementation detail)?

But this is "documented" as a setting.

// Global debug launch configuration. Should be used as an alternative to 'launch.json' that is shared across workspaces.
"launch": {
"configurations": [],
"compounds": []
},

[sandy081]

User launch configuration is supported as a setting, but, IMO it is not the right way and hence user tasks use a separate file.

[rubensa]

So, currently, implementation is "consistent" (as both launch and tasks are supported under settings in devcontainer.json) but documentation is not (according to documentation, launch is supported under settings in devcontainer.json but tasks is not supported).

And, in your opinion, launch support under settings in devcontainer.json should be removed, instead of documenting the support for tasks (and adding it to the XML schema for validation).

Isn't it?

PS: In my opinion, as you can imagine as I opened the issue, this support is useful to allow setting default workspace tasks and launch configurations.

[sandy081]

this support is useful to allow setting default workspace tasks and launch configurations.

Are we doing duplication here? One can have workspace tasks and launches already in the workspace under .vscode folder.

[rubensa]

@sandy081 We want to have some "default" workspace settings pushed to git repository (in .devcontainer/devcontainer.json) + allow for custom developer configs not pushed to git repository (in .vscode/*).

This way, anyone checking out the repository has a default "ready to run" configuration but he is able to "customize" it as needed by setting it's own config under .vscode (which is in .gitignore).

[sandy081]

We want to have some "default" workspace settings pushed to git repository (in .devcontainer/devcontainer.json)

I think this can be pushed into git repository under .vscode folder and users can checkout the repo with these default configurations. This will be helpful if user opens the repository directly (not via dev-container). If users want to change configurations, they can do it locally without checking them to repository.

[rubensa]

But is "difficult" to keep local changes not pushed by mistake.

With my proposal (and current implementation, indeed) you have not to worry about local changes that should not be pushed. The developer is free to have working defaults but also is free to "augment" or "personalize" those.

[sandy081]

But it is preventing to work on the repo just by cloning.

The developer is free to have working defaults but also is free to "augment" or "personalize" those.

This problem is true for all projects. There is already a request to support this feature and it should be supported in the right way. This is just a workaround which seems not to a generic solution.

[rubensa]

As a side note: We also have a mechanism that allows to install some default workspace extensions (by setting them in .devcontainer/devcontainer.json) but allows the developer to "automatically" install custom extensions (by an automatic task that check for the presence of a custom, not git pushed, .devcontainer/extensions.local.json file and installs the extensions defined there). This way the developer does not "lose" any manually installed extension on container rebuild.

[rubensa]

But it is preventing to work on the repo just by cloning.

What do yo mean by "it is preventing to work on the repo just by cloning"? You mean it prevents you to work cause you do not have the VSCode tasks configured? But we are talking about devcontainer development, isn't it? So you wont be able to work just by cloning cause you probably wont have the needed software installed in your "host" machine (as it is not going to use the Docker image and install the needed features...)

This is just a workaround which seems not to a generic solution.

I agree there might be much better solutions (and the pointed proposal of having xx.local.xx files seems very similar to my noted solution for extension installations) but, to me, it is not that bad and is the only "currently" available (indeed, I'm just using it right now in some projects).

[benzman81]

Hi, our team uses a single devcontainer with multiple workspaces since they all require the same setup. However, we're currently forced to copy the necessary tasks into each .code-workspace file, which is error-prone. The only section that needs duplication is the tasks block; all other shared settings are already centralized in the devcontainer file.

Our goal is to have a single file that contains all tasks and settings needed across workspaces, leaving the .code-workspace files to define only the workspace folders. This would streamline our workflow and reduce the risk of errors. We hope this request helps in considering this feature for future releases.

[sandy081]

Our goal is to have a single file that contains all tasks and settings needed across workspaces, leaving the .code-workspace files to define only the workspace folders. This would streamline our workflow and reduce the risk of errors. We hope this request helps in considering this feature for future releases.

@benzman81 This makes sense to me.

My recommendation here is to have separate section/file for tasks in devContainer and on remote machine.

CC @meganrogge I think you are owning tasks feature now.

[rubensa]

As a side note about current implementation on tasks support inside devcontainer.json...

If you have a multi-root workspace defined, and you have a task configured with "runOn": "folderOpen" looks like the task is only run for the first folder in the multi-root workspace (so only run once for the hole workspace, not once per folder defined in the workspace file).

[djpremier]

For me, this functionality is also essential in cases, for example, where the task needs something that does not exist on the person's machine but exists in the devcontainer. Assuming we have an npm install task, if the person does not have NodeJS installed on their machine, the task will generate an error. However, precisely to maintain a clean environment (and without conflicts), we use the DevContainer (and NodeJS will be installed inside it), so a task that should run when opening the project/folder should only be executed if it is in the DevContainer.