Possible to customize Docker image for debug/release in VSCode

We are developing using VSCode and the Torizon plugin. I found that we could customiz our dev-contiainer through the .devcontainer/Dockerfile.template but I have not found a way to do the same for Dockerfile_SDK.debug and Dockerfile.release in the appconfig_0 folder.

The comments in the Dockerfile.release file seems to indicate that it could be customized but when I try to change it my changes gets deleted.

So my question is: how do I customize the release and debug continers?

Hi @rhiev,

I think you can use the buildcommands in the config view of the torizon plugin to include some additional commands to be executed as part of the Docker build.

Also there is some scripts and requirements file for the python projects which I have used for my projects to include additional packages or python libraries. If you use python, you can use them.

Hope this helps.

Regards,
Gaurav

Thank you for replying. I just found the “templates” in the moses-linux/platforms directory and they seem to support your suggestion. One thing I miss, that I’d really like to do is doing something like FROM my/customimage AS customstuff before the torizon FROM. Then I could copy stuff from my customimage to the torizon image. I’ll see if I can work something out from your suggestions.

Just found out that I can accomplish what I want using this

Hi @rhiev,

Are you still having any issues or difficulties with this task?

Best Regards,
Jeremias

I have been able to solve the problem but I don’t love the solution. IMO the “simplifications” that the plugin is offering, so that one cannot edit the Dockerfiles directly, offers no real benefit to how the .devcontainer/Dockerfile.template works, but is rather limiting.
It turned out that I could not access local images from within the devcontainer, so in the end I had to copy files from another image to the appconfig_0 directory and then add a COPY lib /usr/lib to the targetfiles configuration option in the plugin.
Feels very hackish.

I agree that doesn’t sound very ideal. Let me bring this up with our IDE team internally and see if maybe there’s a feature that I’m unaware of that could help here. Or maybe we’ll work on a new feature/improvement based on your feedback.

By the way what exactly are you trying to do/copy to the final container build? It seems like you’re building some external libraries and then passing it on to your final container?

Best Regards,
Jeremias

Thanks @jeremias.tx. You are absolutely right, we have external libs that are not available via apt and we are wrapping those in our own library that we plan to share among several projects.

Alright while your feedback is being discussed internally. I did recall something that we may be able to apply to your situation/use-case here.

Taking this article as a reference: How to Import a C/C++ Application to Torizon | Toradex Developer Center

So the example application in that article relies on an external library (libspectrum). What was done in the article was that the libspectrum source was copied to the same project. Then additional tasks were added to tasks.json. These tasks automate the building and deploying of this library to the work folder so that the library files/binaries were copied to the final application container.

This looks to be a similar situation as your use-case. Would this workflow, be suitable for you as well?

Best Regards,
Jeremias

As we are deprecating the VS Code v1 extensions, I will close this one and set it a solved. But, if there is something yet to be handled let us know @rhiev