Integrate support-service-lambdas with @guardian/devenv by rupertbates · Pull Request #3734 · guardian/support-service-lambdas

rupertbates · 2026-07-27T11:34:08Z

What does this change?

This PR adds a dev container configuration managed by the Guardian Devenv tool to allow us to run support-service-lambdas in a dev container. This provides better isolation of the development environment and limits the impact of issues like supply chain attacks if they occur.

Usage

See the readme in this pull request

Additional optional setup

Provide a dotfiles repo to configure your devcontainer in the same way as your local machine.
This is described in the devenv documentation and I have an example of this here.

johnduffell · 2026-08-31T10:45:54Z

+The standard flow uses a **local checkout only to hold the config**, then has the IDE **clone the sources
+into a container volume** — so there is no bind mount of your working tree.


what does this mean?

When creating the container you can either mount the repo from your local machine or clone it from github, this is saying that in this case we are cloning.

johnduffell · 2026-08-31T15:47:50Z

+4. Create the container from the generated **`user/devcontainer.json`**, using your IDE's
+   clone-into-volume action (this clones the sources into a container volume; your local checkout is
+   not bind-mounted):


it seems like "bind-mounted" means that the container uses the actual workspace directly rather than making an isolated copy.

Suggested change

4. Create the container from the generated **`user/devcontainer.json`**, using your IDE's

clone-into-volume action (this clones the sources into a container volume; your local checkout is

not bind-mounted):

4. Create the container from the generated **`user/devcontainer.json`**, using your IDE's

clone-into-volume action (cloning into a volume means the AI agent cannot see/edit files visible from outside that container workspace):

johnduffell · 2026-08-31T15:53:09Z

+Once the container has been created (see above), you don't need to recreate it — reconnect to the existing
+container instead (this reuses the same cloned-sources volume, so your work is preserved). 


I think this paragraph says very little and could be removed. What would be more useful is a short section on best practice for container reuse - do I use them like branches and create/trash them on each piece of work? Or do I just have one or two and keep using them?

johnduffell · 2026-08-31T16:07:17Z

+### Working inside the container
+
+The `postCreateCommand` (see `devenv.yaml`) already runs `pnpm install` for you as part of the first
+build, so the Node dependencies are ready once the container has finished setting up. Open a terminal
+inside the container and follow the main [README](../README.md) for the Node.js and Scala development
+workflows (building, testing, linting, etc.).


this can probably be deleted once the suggested changes to step 5 above are made.

johnduffell · 2026-08-31T16:40:53Z

+### `shared/devcontainer.json`
+
+A devcontainer configuration generated from `devenv.yaml`, committed to the repository and shared by all
+developers. It contains only the project-wide settings (no personal overrides). It exists so the config can
+be inspected in the repo and used by tooling, but it is **not** the file you normally launch the container
+from — use `user/devcontainer.json` for that (see [Create the dev container](#create-the-dev-container)).
+
+> [!IMPORTANT]
+> Do not edit this file directly! Instead, edit `devenv.yaml` and then run `devenv generate`.
+
+### `user/devcontainer.json`
+
+**This is the file you launch the dev container from** (see [Create the dev container](#create-the-dev-container)).
+It is generated by `devenv generate` from `devenv.yaml` **merged with your personal preferences** (extra VS Code
+extensions or IntelliJ plugins, personal settings/tweaks), and is **git-ignored** (see `.gitignore`) so those
+overrides don't affect other contributors.
+
+To add personal overrides, put them in your user devenv config (`~/.config/devenv/devenv.yaml`) and re-run
+`devenv generate` — do not hand-edit `user/devcontainer.json`, as `devenv generate` will overwrite it.


Suggested change

### `shared/devcontainer.json`

A devcontainer configuration generated from `devenv.yaml`, committed to the repository and shared by all

developers. It contains only the project-wide settings (no personal overrides). It exists so the config can

be inspected in the repo and used by tooling, but it is **not** the file you normally launch the container

from — use `user/devcontainer.json` for that (see [Create the dev container](#create-the-dev-container)).

> [!IMPORTANT]

> Do not edit this file directly! Instead, edit `devenv.yaml` and then run `devenv generate`.

### `user/devcontainer.json`

**This is the file you launch the dev container from** (see [Create the dev container](#create-the-dev-container)).

It is generated by `devenv generate` from `devenv.yaml` **merged with your personal preferences** (extra VS Code

extensions or IntelliJ plugins, personal settings/tweaks), and is **git-ignored** (see `.gitignore`) so those

overrides don't affect other contributors.

To add personal overrides, put them in your user devenv config (`~/.config/devenv/devenv.yaml`) and re-run

`devenv generate` — do not hand-edit `user/devcontainer.json`, as `devenv generate` will overwrite it.

### `shared/devcontainer.json` and `user/devcontainer.json`

Do not edit these - edit `devenv.yaml` and then run `devenv generate`.

The `user` file lets you create your dev container. It includes personal overrides from your user devenv config (`~/.config/devenv/devenv.yaml`) and is gitignored.

The `shared` file is a reference snapshot created from devenv.yaml committed to version control.

johnduffell

thanks for doing this, I've been looking forward to having it. I had a go it seems quite smooth and I'm quite impressed how little we need to add to the repo to enable it (it seems like the README is longer than the code changes needed!)

See inline comments for improvements/suggestions

…gkilled for excessive memory usage

- Promote Open an existing dev container / Working inside the container / Troubleshooting to top-level headings, since they are not part of the "fresh checkout to running container" flow - Replace vague reuse TIP with concrete guidance, and correct the claim about Docker refusing to recreate the container (it actually reuses the volume and reruns postCreateCommand) - Add a troubleshooting note about creating the container from the wrong branch (root cause of a mise install failure reported in review) - Remove boilerplate README.md self-description subsection - Consolidate shared/devcontainer.json and user/devcontainer.json into a single section Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Rerunning postCreateCommand just redoes install steps (mise install, pnpm install etc.) which is slower but not unsafe - all steps use force-overwrite/idempotent operations. Fixes an overstated claim added in the previous commit. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

rupertbates added the maintenance Departmental tracking: maintenance work, not a fix or a feature label Aug 12, 2026

rupertbates changed the title ~~Rb/devcontainer~~ Integrate support-service-lambdas with @guardian/devenv Aug 12, 2026

rupertbates force-pushed the rb/devcontainer branch from 51ed224 to 292579d Compare August 25, 2026 15:42

rupertbates marked this pull request as ready for review August 26, 2026 09:01