Down command

[IgnisDa]

Hello! Is there any ETA for adding the down and stop subcommands? It becomes very tedious to stop the containers manually.

[yokonao]

@chrmarti

Hello! Thank you for all your hard work. I believe that the feature I am thinking of would greatly benefit CLI users.

I was wondering if your project is open to pull request submissions? If so, I would love to implement this feature as my contribution to the amazing work you have done. My team and I have greatly benefited from the devcontainer OSS and I would like to reciprocate by contributing to the project.

[chrmarti]

Hi @yokonao, thanks! Happy to learn the CLI is useful to you. We are indeed open to pull requests. Thank you.

[alexanderilyin]

Workaround while we wait for devcontainer down to be released:

• Add documentation on container/image clean-up for self-hosted runners ci#207 (comment)

[timnolte]

I don't understand why the README in this repo lists the stop & down commands when they don't actually exist yet.

[IgnisDa]

They are not checked in the readme, so I don't think it is misleading.

[timnolte]

@IgnisDa ah, I totally didn't even see the checkboxes, might be related to the GitHub dark theme making them harder to see. Still seems like there isn't much value in having it the README. 🤷🏼‍♂️

[GaTechThomas]

Here's the checkbox contrast issue mentioned above. I just spent a lot of time thinking that I was on an old version of the CLI because this appeared to show a list that was fully complete (or fully incomplete).

[timnolte]

For others looking for this feature, I've actually stopped using this CLI in favor of using the DevPod CLI, which actually has a stop and delete command implemented.

The only catch with using the DevPod CLI/ap is that it implements SSH as the means for getting into the running Dev Container. There is also a desktop UI/app if desired.

I find it way more feature complete and flexible than this CLI. Additionally, the DevPod CLI doesn't require a local NodeJS installed to use.

https://devpod.sh/

[geofflambeth]

Thanks for this recommendation @timnolte! Have you found devpod implements the spec closely enough that users could swap between devpod/vscode/other implementations easily enough?

[timnolte]

@geofflambeth yes, as far as I've tested I haven't seen any issues with using the same devcontainer.json. We are currently using Dev Containers at the agency I work at and most of Devs are using VScode and I use the DevPod CLI since I use Neovim as my IDE.

[bamurtaugh]

Thanks all for the discussion! We'd absolutely welcome a PR to contribute these commands. Additionally, our understanding is DevPod leverages our specification (https://containers.dev/supporting#devpod), so if anyone from / working with DevPod would be similarly interested in contributing down and stop here, that'd be fantastic!

[ruffsl]

Guessing the mechanism for tracking a matching devcontainer exists to some degree given remove-existing-container

cli/src/spec-node/devContainersSpecCLI.ts

Line 119 in 9ba1fda

'remove-existing-container': { type: 'boolean', default: false, description: 'Removes the dev container if it already exists.' },

cli/src/spec-node/singleContainer.ts

Lines 293 to 307 in 9ba1fda

	export async function findExistingContainer(params: DockerResolverParameters, labels: string[]) {
	const { common } = params;
	let container = await findDevContainer(params, labels);
	if (params.expectExistingContainer && !container) {
	throw new ContainerError({ description: 'The expected container does not exist.' });
	}
	if (container && (params.removeOnStartup === true || params.removeOnStartup === container.Id)) {
	const text = 'Removing Existing Container';
	const start = common.output.start(text);
	await removeContainer(params, container.Id);
	common.output.stop(text, start);
	container = undefined;
	}
	return container;
	}