VS Code Torizon Templates has a community template for Node.js + Typescript.
It works as expected.
I have exactly the same need, but some of the npm packages are hosted as private artifacts on Azure DevOps https://pkgs.dev.azure.com/xxxxxxxxxx Private means that an authentication is required, and this is done using vsts-npm-auth as described in the official doc from MS.
I can configure the authentication on WSL (basically it’s a public.npmrc in the project folder , and a private.npmrc in the user home) so that when I run npm install the authentication works.
Now I need to build the container using the Torizon IDE Extension, and so it’s the docker container used to build that must be able to authenticate.
The public.npmrc is copied into the container, but how should I handle the private.npmrc?
Should I copy it to the container too? Which is the path of the user home folder in the container?
The Docker Build Secrets you linked to appear to be a viable solution for this purpose.
It should be possible to use it with the Torizon IDE extension by editing the container build tasks in .vscode/tasks.json.
I think this is because the Torizon IDE extensions calls docker compose build (and not docker build), but it seems that the first one doesn’t have --secret flag - see here.
You are correct, this template uses docker compose build instead of docker build.
Therefore, you actually need to add this configuration on the docker-compose.yml file, as in the following example: How to use secrets in Docker Compose | Docker Docs
Hi @bruno.tx
I did a lot of tests, all of them without success.
And this is the reason (from Docker support)
To make a secret available at build time using Docker Compose, you would typically use build arguments. However, as previously mentioned, this method is not secure for sensitive data, as the build arguments can be cached in the Docker layers.
Unfortunately, as of Docker Compose version 1.25.0+, the ability to use Docker secrets during the build process is not supported. The secrets are only available to the services at runtime, not at build time.
If you need to use secrets during the build process, you might need to consider other methods.
I think that caching secrets in Docker layers is not acceptable and so I need to find another approach.
Is there any specific reason why Toradex decided to use docker compose build instead of docker build?
Do you see any secure alternative/workaround?
It is worth highlighting that the Node.js + Typescript is a community template.
Therefore, it is community maintained.
While a Toradex employee did write this template, it is not a template by Toradex.
To your question, as in most of the other templates we use the docker compose build as well, the docker-compose.yaml file is a convenient way to centralize the build and run configurations for an arbitrary set of containers, without the need to create a task for each of the containers that need to be built in a given project.
An alternative would be to:
Validate that the workflow using docker build works for you, outside of the VSCode extension.
If you want to use the VSCode extension, adapt your project to use the docker build instead of docker compose build.
Regardless, you could submit an issue on the templates repository bringing up this problem.
