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?
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.
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.
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?
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.
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?