Network heavyness of product

[andyi]

Hello,

My usual workflow is to fire devcontainers with everything I need in order to have the right tools in every development computer used by the team.

What I notice with the vscode for stm32 is that now it is harded to pack the tools prior to using the containers.

Configuring the installed extension is not enough because then when the container runs, every st extension downloads a lot of data from the network.

Working with a lot of containers and in a huge team does not scale well because everytime a devcontaner is opened more that 2GB of data are downloaded and unpacked.

This is a waste of network, disk, time resource that could be better used.

There is a way for having the tools packed in a devcontainer? They are the future of reproducible builds and sharing configuration between programmers.

thank you in advance

Andrea

[Nawres GHARBI]

Thank you for sharing your workflow and challenges with STM32CubeIDE for VSCode in devcontainers. Your concerns about network bandwidth, disk usage, and time efficiency when repeatedly downloading large extension toolsets are very valid, especially in large teams using containerized development environments.

If I can please ask a question on how much devcontainers with the extension installed in you are using in your team.

---

How to Pack STM32 Tools in a Devcontainer for Efficient Usage

1. Preinstall STM32 Tools in the Devcontainer Image

The best way to avoid repeated downloads is to build a custom devcontainer image that already contains all required STM32 tools and extensions preinstalled. This approach ensures:

• Tools and dependencies are baked into the container image.
• No need to download or install on container startup.
• Faster container startup and consistent environment across the team.

Steps to build a custom devcontainer image:

• Create a Dockerfile extending your base image (e.g., mcr.microsoft.com/vscode/devcontainers/base).

• In this Dockerfile, install STM32 tools such as:

  • STM32CubeIDE CLI tools or standalone toolchains (ARM GCC, OpenOCD, etc.)
  • VSCode extensions required for STM32 development, pre-downloaded and installed offline.
  • Any other dependencies your workflow requires.

• Use VSCode’s devcontainer.json to point to this custom image.

---

2. Offline VSCode Extension Installation

VSCode extensions for STM32 (like ST’s official extensions) often download additional data on first launch. To avoid this:

• Download VSIX files (VSCode extension packages) manually once.
• Copy these VSIX files into the devcontainer image during build.
• Use the command line to install extensions offline inside the container:

bash

code --install-extension /path/to/extension.vsix

This prevents network downloads on container startup.

---

3. Cache and Share Large Tool Downloads

If some tools or SDKs must be downloaded (e.g., STM32Cube MCU packages):

• Download them once outside the container.
• Mount them as a shared volume inside containers, or
• Copy them into the custom image during build.

This avoids repeated downloads and saves bandwidth.

---

4. Example Dockerfile Snippet

Dockerfile

FROM mcr.microsoft.com/vscode/devcontainers/base:ubuntu

# Install ARM GCC toolchain
RUN apt-get update && apt-get install -y gcc-arm-none-eabi

# Copy STM32Cube packages and tools into image (assumes local folder 'stm32-tools')
COPY stm32-tools /opt/stm32-tools

# Install VSCode extensions offline
COPY extensions/*.vsix /tmp/
RUN for ext in /tmp/*.vsix; do code --install-extension "$ext"; done

# Set environment variables or PATH if needed
ENV PATH="/opt/stm32-tools/bin:${PATH}"

---

5. Best Practices

• Version control your devcontainer Dockerfile and devcontainer.json to ensure reproducibility.
• Use layer caching in Docker builds to speed up rebuilds.
• Share your custom devcontainer image via a private container registry to ensure all team members use the same environment.
• Periodically update your image with new tools or extensions and communicate updates to the team.

---

Summary

Approach	Benefit	Notes
Prebuild custom devcontainer	No runtime downloads, fast startup	Requires Docker image build and maintenance
Offline VSIX extension install	Avoid extension network downloads	Need to maintain VSIX files
Cache SDKs/tools outside container	Save bandwidth and disk space	Use shared volumes or image copy

[andyi]

Thank you for the time that you took for providing this reply.

Sadly in the past one would receive an RTFM reply or a letmegooglethat link. Now a copy and paste from an AI tool.

[mfgkw]

Why not keep the download repo on a network drive available for all?

(NI = no intelligence, just me)

[andyi]

Anyhow...

Every firmware produced lives in it's own project. Every project has its own devcontainer.

Every time a maintenance is performed on a firmware, then the devcontainer is downloaded from our devcontainer private repo and used. 

@mfgkw I partially understand what you are saying. devcontainers are configured for every project in a .devcontainer folder inside vscode. 

When you create the devcontainer you can add tools and libraries, then you can add vscode extensions. 

Then, when the extensions load they could fetch additional software if required.

The AI reply was correct in its own sense, it is basically what you have to do in order to adapt what it is provided to the use case. Those are in any case all acks around something that is in my opinion bad design from the beginning. The extension downloads from the net 2GB of data. That's really a lot.