devcontainers-contrib / features Goto Github PK

Right now the localstack feature is failing its tests (as of the latest commit at time of writing).

The error message that kills the build process is:

AttributeError: module 'distutils.log' has no attribute 'warning'. Did you mean: 'warnings'?

Link to it in the Actions log

The most relevant result from Google seems to be: pypa/setuptools#3707. Here's the PR that supposedly fixes the issue: pypa/setuptools#3709. I don't know what the fix would be. Maybe this is just some issue upstream that will eventually go away?

Right now things don't look to great when you wind up on the repo home page.

To change this, I think that these things could be done:

• Add a header image #68
• Add a more descriptive description #68
• Add a "how to use" section #68
• Add a CONTRIBUTING.md guide #68
• Add details on how to add a new feature Moved to another "better contributor docs" issue #77

I'm looking to create further PRs for the Haskell Feature, but before I do I want to check that I'm on the right path.

Is editing the install.sh and devcontainer-feature.json files directly in this repo the right approach? I observed a conversation about cookie cutter and generating these files, but I'm not sure I'm following the vision for the future.

I'm new to Haskell and learning a little bit of it through Exercism. I want to try it out in a container in VS Code using what appear to be the most popular plug-ins, the Haskell Extension Pack. Does it fit with the design goals for this repo for me to add steps and change defaults so that the base Haskell Feature supports the following scenario?

1. Open a fresh directory with a simple "Hello World" Haskell program in VS Code.
2. Execute the Add Dev Container Configuration Files command
3. Choose Ubuntu with the default jammy version.
4. Add the Haskell Feature listed.
5. Select Reopen in Container.
6. Find the "Haskell Extension Pack" extension and choose to Install it in the Dev Container.
7. Open the HelloWorld.hs file and benefit from the extensions without further action needed.

At present, when I complete the steps above, I see a prompt to download hls-1.8.0.0 and also that hlint cannot be found.

Agreeing to install HLS results in further errors because of version mismatches.

I didn't save my steps, but I got everything working previously and believe I can set up the Haskell Feature to run these extensions out of the box.

@danielbraun89, before I do so: is that a desirable set of changes? If it affects your answer, I'm also planning to do something similar for additional languages that have Exercism tracks (such as Clojure, Elixir, and Scala).

I am completely clueless. I don't know if this is on me, or on the configuration. Looking for a second set of eyes.

I was attempting to pull up a GitHub Codespaces instance to demonstrate the process for the developer-focused wiki (a "Getting started with GitHub Codespaces" section), and ran into the fact that I couldn't get it to work!

The error that kills it is:

write /home/codespace/.local/lib/python3.10/site-packages/torch/lib/libtorch_cpu.so: no space left on device

=================================================================================
2022-11-29 22:02:58.678Z: Configuration starting...
2022-11-29 22:02:58.720Z: Cloning...
2022-11-29 22:02:58.738Z: $ git -C "/var/lib/docker/codespacemount/workspace" clone --branch main --depth 1 https://github.com/devcontainers-contrib/features "/var/lib/docker/codespacemount/workspace/features"
2022-11-29 22:02:58.744Z: Cloning into '/var/lib/docker/codespacemount/workspace/features'...
2022-11-29 22:02:59.096Z: git process exited with exit code 0
2022-11-29 22:02:59.105Z: $ git -C "/var/lib/docker/codespacemount/workspace/features" config --local remote.origin.fetch +refs/heads/*:refs/remotes/origin/*
2022-11-29 22:02:59.111Z: git process exited with exit code 0
2022-11-29 22:02:59.451Z: Using image: mcr.microsoft.com/devcontainers/universal:2

2022-11-29 22:05:55.117Z: #11 ERROR: failed to register layer: ApplyLayer exit status 1 stdout:  stderr: write /home/codespace/.local/lib/python3.10/site-packages/torch/lib/libtorch_cpu.so: no space left on device
2022-11-29 22:05:55.117Z: 
2022-11-29 22:05:55.117Z: #8 [internal] load metadata for mcr.microsoft.com/devcontainers/universal:linux
2022-11-29 22:05:55.117Z: 
2022-11-29 22:05:55.117Z: ------
2022-11-29 22:05:55.117Z: 
2022-11-29 22:05:55.117Z:  > [dev_containers_feature_content_normalize 1/3] FROM mcr.microsoft.com/devcontainers/universal:linux@sha256:5860442949e556cd1ef53ccfa8d45b0a82d09e78910a46a011aa30a769380102:
2022-11-29 22:05:55.117Z: 
2022-11-29 22:05:55.117Z: ------
2022-11-29 22:05:55.117Z: 
2022-11-29 22:05:55.144Z: ERROR: failed to solve: failed to register layer: ApplyLayer exit status 1 stdout:  stderr: write /home/codespace/.local/lib/python3.10/site-packages/torch/lib/libtorch_cpu.so: no space left on device
2022-11-29 22:05:55.145Z: 
2022-11-29 22:05:55.173Z: Stop (171320 ms): Run: docker buildx build --load --build-context dev_containers_feature_content_source=/tmp/devcontainercli-root/container-features/0.23.2-1669759381510 --build-arg _DEV_CONTAINERS_BASE_IMAGE=mcr.microsoft.com/devcontainers/universal:linux --build-arg _DEV_CONTAINERS_IMAGE_USER=root --build-arg _DEV_CONTAINERS_FEATURE_CONTENT_SOURCE=dev_container_feature_content_temp --target dev_containers_target_stage -t vsc-features-1fd731dbdc54187530bf301a0589adb6-features -f /tmp/devcontainercli-root/container-features/0.23.2-1669759381510/Dockerfile.extended /var/lib/docker/codespacemount/.persistedshare/empty-folder
2022-11-29 22:05:55.173Z: Error: Command failed: docker buildx build --load --build-context dev_containers_feature_content_source=/tmp/devcontainercli-root/container-features/0.23.2-1669759381510 --build-arg _DEV_CONTAINERS_BASE_IMAGE=mcr.microsoft.com/devcontainers/universal:linux --build-arg _DEV_CONTAINERS_IMAGE_USER=root --build-arg _DEV_CONTAINERS_FEATURE_CONTENT_SOURCE=dev_container_feature_content_temp --target dev_containers_target_stage -t vsc-features-1fd731dbdc54187530bf301a0589adb6-features -f /tmp/devcontainercli-root/container-features/0.23.2-1669759381510/Dockerfile.extended /var/lib/docker/codespacemount/.persistedshare/empty-folder
2022-11-29 22:05:55.173Z:     at loe (/usr/lib/node_modules/@microsoft/vscode-dev-containers-cli/dist/spec-node/devContainersSpecCLI.js:1887:1339)
2022-11-29 22:05:55.173Z:     at eT (/usr/lib/node_modules/@microsoft/vscode-dev-containers-cli/dist/spec-node/devContainersSpecCLI.js:1887:1275)
2022-11-29 22:05:55.173Z:     at processTicksAndRejections (internal/process/task_queues.js:95:5)
2022-11-29 22:05:55.174Z:     at async voe (/usr/lib/node_modules/@microsoft/vscode-dev-containers-cli/dist/spec-node/devContainersSpecCLI.js:1893:2049)
2022-11-29 22:05:55.174Z:     at async Xf (/usr/lib/node_modules/@microsoft/vscode-dev-containers-cli/dist/spec-node/devContainersSpecCLI.js:1893:3212)
2022-11-29 22:05:55.174Z:     at async Jae (/usr/lib/node_modules/@microsoft/vscode-dev-containers-cli/dist/spec-node/devContainersSpecCLI.js:2013:15058)
2022-11-29 22:05:55.174Z:     at async Wae (/usr/lib/node_modules/@microsoft/vscode-dev-containers-cli/dist/spec-node/devContainersSpecCLI.js:2013:14812)
2022-11-29 22:05:55.217Z: Stop (174414 ms): Run: /usr/bin/node /usr/lib/node_modules/@microsoft/vscode-dev-containers-cli/dist/spec-node/devContainersSpecCLI.js up --user-data-folder /var/lib/docker/codespacemount/.persistedshare --container-data-folder .vscode-remote/data/Machine --container-system-data-folder /var/vscode-remote --workspace-folder /var/lib/docker/codespacemount/workspace/features --id-label Type=codespaces --log-level info --log-format json --config /var/lib/docker/codespacemount/workspace/features/.devcontainer/devcontainer.json --override-config /root/.codespaces/shared/merged_devcontainer.json --default-user-env-probe loginInteractiveShell --mount type=bind,source=/.codespaces/agent/mount/cache,target=/vscode --skip-post-create --update-remote-user-uid-default never --mount-workspace-git-root false
2022-11-29 22:05:55.217Z: Exit code 1

====================================== ERROR ====================================
2022-11-29 22:05:55.246Z: Failed to create container.
=================================================================================
2022-11-29 22:05:55.255Z: Error: Command failed: /usr/bin/node /usr/lib/node_modules/@microsoft/vscode-dev-containers-cli/dist/spec-node/devContainersSpecCLI.js up --user-data-folder /var/lib/docker/codespacemount/.persistedshare --container-data-folder .vscode-remote/data/Machine --container-system-data-folder /var/vscode-remote --workspace-folder /var/lib/docker/codespacemount/workspace/features --id-label Type=codespaces --log-level info --log-format json --config /var/lib/docker/codespacemount/workspace/features/.devcontainer/devcontainer.json --override-config /root/.codespaces/shared/merged_devcontainer.json --default-user-env-probe loginInteractiveShell --mount type=bind,source=/.codespaces/agent/mount/cache,target=/vscode --skip-post-create --update-remote-user-uid-default never --mount-workspace-git-root false
2022-11-29 22:05:55.267Z: Error Code: 1302

====================================== ERROR ====================================
2022-11-29 22:05:55.300Z: Container creation failed.
=================================================================================

So yeah... I don't think this is a huge problem since I was able to get my own copy (my jcbhmr/devcontainers-contrib-features fork) working just fine. I don't know why it borked when I tried to create one on the main devcontainers-contrib/features proper though.

Should support package injection
Should install pipx if not exists
Should install python if not exists

Document links set in some Features seem to be broken.

I'm wondering if you should use snake_case here.
Note that all devcontainers's features use camelCase.

Minor suggestion to manually clean up the apt lists that this Feature will generate (like devcontainers/features#210). This will make the final image size a bit smaller.

Hi, @danielbraun89.
You have recently released apt-get-packages in ccd4c1f, but there is already a functionality equivalent to this that has been released.

https://github.com/rocker-org/devcontainer-features/blob/main/src/apt-packages

Were you aware of this?
Wouldn't it be better to manage one jointly than two similar ones?

I have run into this same thing in the past.
devcontainers/spec#155

Opened in response to the discussion in #171. This is an issue tracking implementation progress.

After some consideration and discussion in #171, I think the scope of this repo should be severely restricted. Sure, lots of other features can be added like Haskell, Heroku's CLI, etc. should all be included... But I don't think we need a jest package if we add a "packages" field of some kind to a generic Node.js feature. This is my opinion.

TL;DR: Make generic ecosystems like Haskell, Python, Node.js, etc. accept arbitrary package installers instead of splintering them into their own features.

{
  "image": "mcr.microsoft.com/devcontainers/universal:linux",
  "features": {
    "ghcr.io/devcontainers-contrib/features/python:1": {
      "packages": ["bikeshed~=3.1.0", "pylint==2.10.0"]
    },
    "ghcr.io/devcontainers-contrib/features/node:1": {
      "packages": {
        "typescript": "^4.8.0",
        "prettier": "latest"
      }
    }
  }
}

See advantages/disadvantages in #171

Tasks

• Start a jcbhmr/devcontainers-contrib-features-172 repo
• Research whether or not objects can be passed to the options of a feature
• Add support to the Node.js feature for a "packages" option of some kind
• Add support to the Python feature for a "packages" option
• Demonstrate real-world implications of this change
• Add documentation describing why this is better/worse and alternatives
• Draw a distinction in user guides between when to use Features and when to use Dockerfiles

Moved to #81

Original

This doesn't actually deal with the features repo, but the entire org itself

Similar to the actual devcontainers organization, I think it might be wise to add a little touch of customization to the organization home page.

Side-by-side comparison:

devcontainers	devcontainers-contrib

Suggestions:

• Add a devcontainers-contrib/devcontainers-contrib repo with a README.md that might even be as simple as my profile's readme
• Add a custom profile image
  • Maybe the devcontainer logo copy-pasted same as vercel-community
  • Maybe the devcontainer logo with a big stamp of something over the top of it to signify "community"

started this issue for the @DaneWeber PR #74

Using a simple configuration, Pulumi fails to install with its default parameters:

{
    "name": "devcontainer",
    "image": "mcr.microsoft.com/devcontainers/base:bullseye",
    "features": {
        "ghcr.io/devcontainers-contrib/features/pulumi:1": {}
    }
}

From the container log, the relevant part seems to be the "Permission denied" errors for creating a symbolic link and for bash completion.

#0 11.20 === Pulumi is now installed! 🍹 ===
#0 11.20 + Please restart your shell or add /home/vscode/.pulumi/bin to your $PATH
#0 11.20 + Get started with Pulumi: https://www.pulumi.com/docs/quickstart
#0 11.20 ln: failed to create symbolic link '/usr/local/bin/pulumi': Permission denied
#0 11.21 /bin/bash: line 7: /etc/bash_completion.d/pulumi: Permission denied
#0 11.21 ERROR: Feature "Pulumi" (ghcr.io/devcontainers-contrib/features/pulumi) failed to install! Look at the documentation at https://github.com/devcontainers-contrib/features/tree/main/src/pulumi for help troubleshooting this error.

Setting `"BASHCOMPLETION":false' like so:

"ghcr.io/devcontainers-contrib/features/pulumi:1": {"BASHCOMPLETION":false}

allows the container to be successfully built.

I think @danielbraun89 is the only one with the power to do this.

It would probably be beneficial to add a Goals.md page to the Wiki which outlines the current scope and covered use-cases for this feature collection.

With recent discussion about "what is the scope of features in this repo?" and "what should be a feature?", I think it would be a good idea to consolidate these into a single document. This shouldn't necessarily happen now given that discussion is still ongoing, but it would be foolish to think that we all (@DaneWeber @danielbraun89 and @jcbhmr being primary discuss-ers) remember the gist of like 100+ comments over 10+ threads about goals and scope of this project.

Relevant discussions: #171 #173 #175 #172

Tasks

• Add a Goals.md to the wiki/ folder
• Answer "what is the goal of this repo?"
• Answer "what qualifies as a feature?"
• Link to relevant discussions for more details

Should this file be called something else? Maybe folded into the wiki/README.md file?

/assign @jcbhmr

Hello,

When:

• using both angular-cli and node features
• if setting version of the node feature

The angular-cli script will run first and run its own nvm install script. Then, the node feature will run and update the default alias of node. This makes the installed angular-cli inaccessible in the container (by default).

Related/same issue: the angular-cli overlooks nvm installed node regardless of whether a the node feature was used for installation. Presumably because it's not using an interactive shell to check for node.

Using a very basic config:

{
    "name": "devcontainer",
    "image": "mcr.microsoft.com/devcontainers/base:bullseye",
    "features": {
        "ghcr.io/devcontainers-contrib/features/pulumi:1": {}
    }
}

pulumi cli will be only available for the root user, not the default UID=1000 user that is logged in by default.

This is related to #69 and #75 , but tackles the improvement of developer guides instead of user guides.

Does a Wiki make sense for developer-focused docs? I actively wish 👍✅ or 👎⛔ opinions to see if something else would be better/wanted.

Tasks

• Add an actual guide/walkthrough to create a new feature somewhere (GitHub Wiki or CONTRIBUTING.md)
• Create a Wiki based on my docs philosophy (see below) with all the nitty gritty guides to add/modify stuff and patterns to follow
  • Detail why we need a check_package function
  • Describe why the repo is structured the way it is (src and test)
  • Explain what that magical source dev-container-features-test-lib does
  • Explain why these features are all grouped in one repo instead of separate repos
  • Explain what exec $SHELL does
• Trim some of the auto-generated fat off of the CONTRIBUTING.md? 🟨 Is this a good idea?

If we do make a Wiki for explanations, I recommend that it be tied to a wiki/ folder auto-synced on each push to the actual "published" Wiki tab on GitHub. Sure you could just link to the wiki/Your-title-here.md files like https://github.com/user/repo/tree/main/blob/wiki/Your-title-here.md, but I think it's nicer with the Wiki's auto-generated sidebar, Table of Contents, etc. It's more "website"-looking. Here's a GitHub Action that does this

I notice that some PRs are reformatting things. I think we should run a code formatted over everything in one big PR to prevent additional superfluous commits in other PRs. Should this be done?

Also, should this repo have a styleguide? Is it large enough to warrant that? If so what format? Anything goes? Use Prettier? Use Prettier shell-formatter plugin?

Tasks

• Prettier/format all files
• Add a style guide instruction/notice in CONTRIBUTING.md
• Add a GitHub Action to auto format new PRs or just main or something else

Feel free to "Close as not planned" if this isn't important.

Separately: please add a real email for security issues soon (or other instructions for reporting security issues) --> https://github.com/devcontainers-contrib/features/blame/main/CONTRIBUTING.md#L48

-- @DaneWeber in #77 (comment)

Also...

• Consider a SECURITY.md
• Consider putting such information at an org-level instead of at a repo-level #81

I think it should probably be @danielbraun89, the owner and sole "actual member" of the @devcontainers-contrib org.

add feature to install ansible-collections if variable is defined

There are a lot of these:

TODO: Add suggestions to fix here @jcbhmr

Here's what causes these warnings and how to solve them:

• Please update the following actions to use Node.js 16: actions/checkout@v2
• The set-output command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/ (this refers to the find-features action that uses set-output stuff)

That's it! There are so many errors with the same message since the same action is being run in a matrix (and thus the same actions/checkout@v2 is triggering warnings a lot).

while feature generation going to be refactored in the future as a result of discussion in #75
However in meantime to avoid confusion the current process should be better documented

I humbly suggest that one of the admins with the power to do change the repository's "Description" field from "Contributions are Welcomed!" to "🐳 Extra add-in features for Devcontainers and GitHub Codespaces". This description field is sort of the "title" for Google search results. I think it would be wise to make it a more substantive description.

I personally try to keep the repo-level Description field the same as the tag-line-ish thing that I always put under the <h1> in the readme.

Originally posted by @jcbhmr in #69 (comment)

My honest opinion on the whole Cookiecutter thing:

It's too complicated. There is too much logic concentrated in a template file that belongs in separate scripting files. Cookiecutter and Yeoman (and any project generator really) are great tools, but I don't think they fit the bill the best here.

They work but it's unwieldy to edit them. The files are too big for what they should be. There should be a separate npm-devcontainer-feature.json and one for pip-devcontainer-feature.json if you keep Cookiecutter IMO. They also spread the logic too far apart. You need to reference variables that you declare in JSON and use in Jinja. You need to declare functions separately. You need dependency management. It's a mess.

An alternative is to split each "type" (NPM, pip, apt) into its own Cookiecutter package, but I think a better option is to ditch Cookiecutter as too overkill for simple file generation.

Take Angular for instance. They use ng generate <type> as a way to create new components, interfaces, app shells, and more. I think this approach of script-based generation should be adopted going forward instead of more complex unweidly (and frankly very intimidating) Cookiecutter template logic. I mean have you seen that devcontainer-feature.json file? It is write-once and never touch again code at its finest.

Another argument is that we really need freaking examples of how to do this? Is it really that complicated to just fill out a form in your terminal basically?

Here's an example to really nail home what I am talking about. This is a complete Feature generator script that works! I just wrote it so it might not have proper error handling. It generates an NPM-based feature.

Try it out on Replit! It actually works! https://replit.com/@jcbhmr/SquigglyRepulsiveSolaris#index.js

#!/usr/bin/env -S deno run -A
const npmName = prompt("What is the name of the NPM package?");
const featName = prompt("What should the feature name be?");
const featId = prompt("What should the feature ID be?");
const featDesc = prompt("What should the feature description be?");
const featTestCmd = prompt("What should the test command be?");

const featObject = {
  name: featName,
  description: featDesc,
  id: featId,
  version: "1.0.0",
  documentationURL: `https://github.com/devcontainers-contrib/features/tree/main/src/${featId}#readme`,
  installAfter: ["ghcr.io/devcontainers/features/node:1"],
  options: {
    version: {
      type: "boolean",
      proposals: ["latest"],
      default: "latest",
      description: `Select the version of ${npmName}`,
    },
  },
};
const featJSON = JSON.stringify(featObject, 0, 4);

const featInstallSH = `#!/usr/bin/env bash
set -Eeuo pipefail

if ! command -v npm &>/dev/null; then
  echo "WARN: 'npm' was not found. Installing Node.js + NPM using devcontainer/features src/node/install.sh..."
  curl -fsSL https://raw.githubusercontent.com/devcontainers/features/main/src/node/install.sh | /bin/bash
fi

npm i -g ${npmName}@\${VERSION:-"latest"}
`;

const featTestSH = `#!/usr/bin/env bash
set -Eeuo pipefail

${featTestCmd}
`;

console.log(`src/${featId}/devcontainer-feature.json`);
console.log(featJSON);
console.log(`src/${featId}/install.sh`);
console.log(featInstallSH);
console.log(`test/${featId}/test.sh`);
console.log(featTestSH);

await Deno.mkdir(`src/${featId}`, { recursive: true }); // Same as 'mkdir -p <folder>'.
await Deno.writeTextFile(`src/${featId}/devcontainer-feature.json`, featJSON);
await Deno.writeTextFile(`src/${featId}/install.sh`, featInstallSH);
await Deno.chmod(`src/${featId}/install.sh`, 0o755); // Default of 'chmod +x <file>' is 755.
await Deno.mkdir(`test/${featId}`, { recursive: true });
await Deno.writeTextFile(`test/${featId}/test.sh`, featTestSH);

Then the user experience is so much better! You just run the script and it does it for you. You can even "infer" things from the current Git repo like the remote origin URL for documentation URL generation! And it makes it easier to add new features without coupling them to other features (ie. not as many if-statements). I know you can probably do that in Cookiecutter too, but this is one file instead of like 5 files in 3 directories. It's easier to reason about, follow, and maintain. Especially when compared to that monster of an install.sh template.

For instance, here are some generator script ideas:

• scripts/generate-new-feature-pip.js
• scripts/generate-new-feature-apt.py
• scripts/generate-new-feature-deno.sh
• scripts/generate-new-feature-brew.rb
• scripts/generate-new-feature-${yourPackageManager}.${yourFavoriteScriptingLanguage}

Heck, you could even commit a C++ file that compiled and ran itself if you really wanted to!

TL;DR: I want a 👍✅ or a 👎⛔ before I invest more time. If I do all the work and the PR doesn't merge, that's not fun for me 😭.

PS: Yes, you can use Python if you're into Python over TypeScript/JavaScript. I personally like the ability of JavaScript + Deno to be self-contained in a single file even if it includes library stuff using HTTP import URLs.

// Using the Prettier code formatter which is relatively large. It's one URL import away!
// https://github.com/denolib/prettier#readme
import { prettier, prettierPlugins } from "https://denolib.com/denolib/prettier/prettier.ts";

const json = JSON.stringify({ my: "object" })
const opts = { parser: "json", plugins: prettierPlugins };
prettier.format(json, opts);
//=> '{ "my": "object" }\n'

Originally posted by @jcbhmr in #69 (comment)

Currently each feature test is being run in its own action runner which is limited by github to 256 (https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs)

Possible solution is to run the tests in a single runner

Must ensure:

• it is highly parallel in order to decrease run time
• can print logs of all tests in a structured and easily read order

While the wiki/ folder is designed to work as standalone in-source documentation, the links (like the ones in the readme) assume that there is a https://github.com/devcontainers-contrib/features/wiki. This requires turning on the GitHub Wiki in the Settings tab. It will auto-publish using a GitHub Action.

https://github.com/devcontainers-contrib/features/actions/workflows/Publish%20the%20dev%20wiki.yml

on:
  push:
    branches: [main]
    paths: [wiki/**, .github/workflows/Publish the dev wiki.yml]
# ...

@danielbraun89 is the only one with access to do this (I think)

The install.sh for asdf-package contains an environment variable for PLUGINREPO, but there is currently no option to populate the variable.

on push to main - all features will be regenerated and a new PR with new features will be opened
(new features will be tested in the PR test workflow)

in case no changes were detected (generated features are identical to current features) then the PR should not be opened

Others have also had problems with root user vs normal user.

• devcontainers/spec#91
• #149
• #144
• #139
• #137
• #94
• #80
• #74
• https://github.com/devcontainers/spec/blob/main/proposals/features-user-env-variables.md

It would be beneficial to have documentation on how to fix it and why it happens.

/assign @jcbhmr

Any suggestions anyone to help catch these earlier? Something in the test/ folder maybe? More robust shell testing?

I haven't looked into what's required, but I'd think supporting the following would Pretty Darn Good:

• Run the tests as a non-root user (the REMOTE_USER such as vscode)
• Provide a .devcontainer.json for each test suite. In particular, I'd like to run tests with defaults and another with specified values.
• Besides looking for the check commands to run without error, it would be cool to run regex patterns against the output for higher-fidelity but resilient tests.

Some of these installs download a ton of data, so it might be important to cache the downloads somehow.

Originally posted by @DaneWeber in #137 (comment)

I think at a higher level, in terms of devcontainer fixtures, it would make sense to have an integration/smoke test (that runs on everything, not something that every feature has to maintain separately), which actually creates a devcontainer with the feature. I'm not entirely sure how to do that programmatically.

It might be sufficient to have a test that pulls a basic docker image, or even the base devcontainer image, and then checks out the feature and runs install.sh inside of it. That probably would have been enough to catch this. I can give that a try soon, and see if it's as easy as I'm claiming. 😆

Originally posted by @fred-asimov in #137 (comment)

There has been a recurring issue where things get merged, all tests pass, and then something like "it literally fails to install because it uses the wrong user account" crops up.

To move foward, I think more testing or at least better testing should be considered. DaneWeber and fred-asimov bring up good ideas (quoted above) that should be considered.

This is not time sensitive and should probably stay open a while. It should be in the back of your mind when making changes