Open TorbenWetter opened 1 year ago
Hi 👋
Thanks for opening the issue and for your kind words ✨
@TorbenWetter what's the version of your @devcontainers/cli
package? You can find it with devcontainer --version
command.
@chrmarti Could this be related to the lockfile changes? or any other recent changes? 🤔
Hey @samruddhikhandale!
I'm using the most recent version of the CLI:
$ devcontainer --version
0.50.0
Here's the version of VS Code I'm currently using:
What I couldn't confirm is whether the image files (.jpg
/.png
) undergo modifications during the build process itself, or when the template is applied by either VS Code or the CLI.
Oh, and not to forget:
Dev Containers VS Code extension version v0.299.0
.
Found that we convert all files to text and back which does not preserve binary content and created a PR from my investigation.
I want to express my sincere appreciation for making Dev Containers a reality; I've been a huge fan since its launch! Over the past few months, I've put together my own template, which can be found here: https://github.com/TorbenWetter/iu-latex-container-templates
The Problem
Up until now, everything has been running smoothly. Files with extensions like
.tex
or.bib
have been effortlessly incorporated into my Dev Container. However, today I attempted to add image files to mythesis
template, including.jpg
and.png
files. While loading the template in VS Code usingAdd Dev Container Configuration Files...
from the Dev Containers extension, I observed that the hash/checksum of the image files differed from those in my template's GitHub repository. Regrettably, this discrepancy rendered them incompatible with my LaTeX environment. Although I wasn't able to delve into this issue further, I concentrated on examining the behaviour of the Dev Containers CLI.Reproduction Process
In an attempt to discern what was occurring with the images, I cloned my repository, applied the template via the Dev Containers CLI, and then compared the checksums of the images:
I'm more than willing to further investigate this issue, but so far, my independent attempts to pinpoint the problem with the CLI by scrutinizing the code have been fruitless.