Add devcontainer.json manager to Renovate

[HonkingGoose]

What would you like Renovate to be able to do?

Opening a issue for this idea, so that it doesn't get lost in the discussion forum. 😉

Quote from @rarkins ¹

I think devcontainer.json is widely enough used now that we should consider giving it its own "manager" in Renovate

If you have any ideas on how this should be implemented, please tell us here.

Nope, I'll let the code-wizards figure it out. 😉

Is this a feature you are interested in implementing yourself?

No

Footnotes

1. https://github.com/renovatebot/renovate/discussions/12114#discussioncomment-1458593 ↩

[github-actions]

Hi there,

You're requesting support for a new package manager. We need to know some basic information about this package manager first. Please copy/paste the new package manager questionnaire, and fill it out in full.

Once the questionnaire is filled out we will evaluate if adding support for this manager is something we want to do.

Good luck,

The Renovate team

[HonkingGoose]

Click me to see filled out questionnaire

New package manager questionnaire

Did you read our documentation on adding a package manager?

• I've read the adding a package manager documentation.

Basics

Name of package manager

devcontainer manager

What language does this support?

A devcontainer.json file in your project tells VS Code how to access (or create) a development container with a well-defined tool and runtime stack. This container can be used to run an application or to separate tools, libraries, or runtimes needed for working with a codebase.

How popular is this package manager?

GitHub Codespaces supports the devcontainer.json format already, and Gitpod is working on adding support.

Does this language have other (competing?) package managers?

• Yes (give names)
• No

---

Package File Detection

What type of package files and names does it use?

The dev container configuration is either located under .devcontainer/devcontainer.json or stored as a .devcontainer.json file (note the dot-prefix) in the root of your project. ¹

What fileMatch pattern(s) should be used?

• We should match on .devcontainer.json in the root of the repository.
• We should also match on devcontainer.json (without the dot-prefix!) in the .devcontainer directory.

Is it likely that many users would need to extend this pattern for custom file names?

• Yes
• No

I don't expect people will use different filenames/locations for their devcontainer file as that will not conform to the spec and likely not even work properly with Codespaces or VSCode... 😄

Is the fileMatch pattern likely to get many "false hits" for files that have nothing to do with package management?

I don't think we'll get false hits.

---

Parsing and Extraction

Can package files have "local" links to each other that need to be resolved?

A Dockerfile will also live in the .devcontainer folder. You can replace the image property in devcontainer.json with dockerFile:

You can link to a Dockerfile from within a devcontainer.json file, like this: ²

{
  "build": { "dockerfile": "Dockerfile" },
  "extensions": ["dbaeumer.vscode-eslint"],
  "forwardPorts": [3000]
}

The idea is that your Devcontainer file gathers all requirements in a single place, like the image, Dockerfile or Docker Compose file so that VSCode, GitHub Codespaces or Gitpod knows how to setup the container.

Is there a reason why package files need to be parsed together (in serial) instead of independently?

No clue what this means.

What format/syntax is the package file in?

• JSON
• TOML
• YAML
• Custom (explain below)

How do you suggest parsing the file?

• Off the shelf parser
• Using regex
• Custom-parsed line by line
• Other

I guess we can find the correct files by writing a bit of regex.

Does the package file structure distinguish between different "types" of dependencies? e.g. production dependencies, dev dependencies, etc?

• Yes, production and development dependencies
• No, all dependencies are treated the same

List all the sources/syntaxes of dependencies that can be extracted

I think theses are the images, Dockerfiles or Docker Compose files that you can put in the devcontainer file:

• image
• build.dockerfile Link to other file
• dockerfile Link to other file
• dockerComposeFile Link to other file

Describe which types of dependencies above are supported and which will be implemented in future

I think these are all supported already by GitHub Codespaces:

• image
• build.dockerfile
• dockerfile
• dockerComposeFile

---

Versioning

What versioning scheme does the package file(s) use?

It depends on what image, Dockerfile or Docker Compose file(s) you link to what versioning scheme is used.

Does this versioning scheme support range constraints, e.g. ^1.0.0 or 1.x?

• Supports range constraints (e.g ^1.0.0 or 1.x)
• No

Not 100% sure here.

I think you usually always pin your image, Dockerfile or Docker Compose to a specific image, tag or digest. But you could use a tag like mysql:latest and get the latest release automatically when pulling. So that's kind of a range syntax... 😄

Is this package manager used for applications, libraries, or both? If both, is there a way to tell which is which?

• Applications
• Libraries
• Both (explain how to tell which is which)

You can use this file for development containers, those containers can be used to work on applications or libraries.

If ranges are supported, are there any cases when Renovate should pin ranges to exact versions if rangeStrategy=auto?

---

Lookup

Is a new datasource required? Provide details

• Yes, provide details.
• No.

I think we can use our Dockerfile datasource as a template to get most of the way there. But we might still need specific things to work with the devcontainer files. I'll let the maintainers decide. 😉

Will users need the capability to specify a custom host/registry to look up? Can it be found within the package files, or within other files inside the repository, or would it require Renovate configuration?

People can set their own container registry if they use the image property in their devcontainer file:

Property	Type	Description
Dockerfile or image
image	string	Required when using an image. The name of an image in a container registry (DockerHub, GitHub Container Registry, Azure Container Registry) that VS Code should use to create the dev container.

Do the package files contain any "constraints" on the parent language (e.g. supports only v3.x of Python) or platform (Linux, Windows, etc) that should be used in the lookup procedure?

No idea.

Will users need the ability to configure language or other constraints using Renovate config?

No idea.

---

Artifacts

Are lock files or checksum files used? Are they mandatory?

No lock files or checksum files used.

If so, what tool and exact commands should be used if updating one or more package versions in a dependency file?

If applicable, describe how the tool maintains a cache and if it can be controlled via CLI or env? Do you recommend the cache be kept or disabled/ignored?

If applicable, what command should be used to generate a lock file from scratch if you already have a package file? This will be used for "lock file maintenance"

Other

Is there anything else to know about this package manager?

I found a full reference for the devcontainer.json file. ³

Footnotes

1. https://code.visualstudio.com/docs/remote/containers#_create-a-devcontainerjson-file ↩

2. https://code.visualstudio.com/docs/remote/create-dev-container#_dockerfile ↩

3. https://code.visualstudio.com/docs/remote/devcontainerjson-reference ↩

[apgrucza]

In addition to the image property, the devcontainer.json file also contains versions in the features property. Renovate needs to process these too. Both feature versions and package versions can appear in this object (see below example from https://containers.dev/implementors/features/#devcontainer-json-properties):

"features": {
  "ghcr.io/user/repo/go": {},
  "ghcr.io/user/repo1/go:1": {},
  "ghcr.io/user/repo2/go:latest": {},
  "https://github.com/user/repo/releases/devcontainer-feature-go.tgz": { 
        "optionA": "value" 
  },
  "./myGoFeature": { 
        "optionA": true,
        "optionB": "hello",
        "version" : "1.0.0"
  }
}

[lmilbaum]

The features are also versioned. vscode provides an extension which identifies outdated feature versions and provides the ability to populate the latest version. I've noticed that when editing the devcontainer.json file.

[electriquo]

following #25338 (reply in thread), we could probably leverage the regex manager to update the image within devcontainer files by tweaking its presets in https://github.com/renovatebot/renovate/blob/main/lib/config/presets/internal/regex-managers.ts

maybe adding the following will due

  devcontainerVersions: {
    customManagers: [
      {
        customType: 'regex',
        fileMatch: [
          '\^.devcontainer/devcontainer.json$',
          '^.devcontainer.json$',
        ],
        matchStrings: [
          '\\s*"image":\\s"(?<registryUrls>.*?)\\/(?<depName>.*?):(?<currentValue>.*?)(@(?<currentDigest>sha256:[a-f0-9]+))?"',
        ],
      },
    ],
    description: 'Update image version in devcontainer files.',
  },

sorry for posting rather than contributing directly by a pr.

[lmilbaum]

JFYI,

1. The devcontainer CLI is used by vscode and dependabot for bumping features. The command is: devcontainer outdated.
2. The devcontainer lockfile is updated with the command: devcontainer upgrade
3. The dependabot integration - https://containers.dev/guide/dependabot

[renovate-release]

🎉 This issue has been resolved in version 37.322.0 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)
• 37.322.0

Your semantic-release bot 📦🚀