DevContainer must rebuild everytime VS Code launches

[richb-hanover]

What's up?

The Dev Container works well, but its user experience is kinda rocky. I'm using a MacBook Pro, macOS 12.6.3, latest Docker, VS Code, etc. I'm reporting this in case there's something wrong/screwy. I posted a video screen shot at https://youtu.be/BMh-ilwXbzE Here's what I see:

Each time I start up VS Code, I get a warning that devcontainer.json has changed. (It hasn't - at least I haven't changed it intentionally.) When I click the Rebuild button, I frequently get an alert "An error occurred setting up the container." Clicking Retry usually restarts the Dev Container and it progresses as desired.

At the point I see the "Press any key..." message in the console, I then see the "Acquiring CodeLLDB..." message. This progresses rapidly, then goes away. I can then use the Dev Container.

Other observations:

1. I can task run-playground or task run-playground-cached immediately.
2. task run-book gives an error Blocking waiting for file lock on build directory until the rust analyzer has completed all its checks.
3. Why does rust-analyzer need to run every time the Dev Container starts up? Is that expected?

What other information could I provide? Thanks.

[max-sixty]

That does look unfriendly, particularly the initial 30 seconds. I'm not sure how much is on PRQL vs Microsoft...

Thanks for the video, that makes it visceral (and nice theme!).

Possibly #2898 could help?? (not confident though)

• task run-book gives an error Blocking waiting for file lock on build directory until the rust analyzer has completed all its checks.

• Why does rust-analyzer need to run every time the Dev Container starts up? Is that expected?

Yes, the caching is exclusive. rust-analyzer is the Rust LSP tool — it's awesome! It's always running. Once it's done an initial compilation, I haven't notice it be resource-heavy at all.

[richb-hanover]

I'm just reporting this so that we can review the user experience as we move along. To summarize:

• devcontainer.json - That file hasn't changed (on my disk) since 17 June, yet VS Code reports that it has...

• rust-analyzer - it takes most of five minutes to build everything on my Macbook Pro. The rust code on my machine never changes between launches of VS Code. Is any caching available? (I agree that once it's cached, it doesn't consume many resources.)

• Theme - it's Solarized Light. I find a light theme is easier for my old-guy eyes. The light background "stops down" my eyes/iris to help focus the text.

• I'm not requesting any changes - the Dev Container works fine.

Thanks again.

[eitsupi]

At the point I see the "Press any key..." message in the console, I then see the "Acquiring CodeLLDB..." message. This progresses rapidly, then goes away. I can then use the Dev Container.

task run-book gives an error Blocking waiting for file lock on build directory until the rust analyzer has completed all its checks.

I think these are rust-analizer issues, not Microsoft or PRQL.

DevContainer must rebuild everytime VS Code launches

The toast that devcontainer.json has been updated can simply be ignored. Not "must".
I simply recreate the container in my timing.

[eitsupi]

Each time I start up VS Code, I get a warning that devcontainer.json has changed. (It hasn't - at least I haven't changed it intentionally.)

Is this because the devcontainer.json in the repository has changed?
This means that even if devcontainer.json is changed by switching branches, the toast should appear.

I have never actually seen this toast appear even though the devcontainer.json has not changed. I have been doing almost all my programming work on Dev Containers for the past 3 years.

When I click the Rebuild button, I frequently get an alert "An error occurred setting up the container." Clicking Retry usually restarts the Dev Container and it progresses as desired.

I see this a lot, not just in this repository, but I think it is simply VSCode working faster than the container termination and startup process controlled by Docker and the connection is not working. If you think this is a bug, please report it here. https://github.com/microsoft/vscode-remote-release

[eitsupi]

rust-analyzer - it takes most of five minutes to build everything on my Macbook Pro. The rust code on my machine never changes between launches of VS Code. Is any caching available? (I agree that once it's cached, it doesn't consume many resources.)

I am not familiar with rust-analizer, but perhaps the implicit build time is reduced because duckdb-rs is removed as a default development dependency? (#2899)
(DuckDB builds are really painfull......)

[richb-hanover]

@eitsupi

Each time I start up VS Code, I get a warning that devcontainer.json has changed. (It hasn't - at least I haven't changed it intentionally.)
Is this because the devcontainer.json in the repository has changed?

This happens even if I start VS Code, let it fully bring up the Dev Container (including all the rust-analyzer time), then quit VS Code (without making any changes), then restart it. Could it occur because I just quit (Cmd-Q) from VS Code without any other warning?

I can live with this just fine - I'm just following my company's old slogan [1] by pointing it out. Thank you again.

[1] "We promise not to fix it if we don't know it's broke." :-)

[eitsupi]

This happens even if I start VS Code, let it fully bring up the Dev Container (including all the rust-analyzer time), then quit VS Code (without making any changes), then restart it. Could it occur because I just quit (Cmd-Q) from VS Code without any other warning?

VSCode should compare the latest devcontainer.json with the devcontainer.json used to build the container. So whether you see toast or not depends on when you last built the container.
Please check the official document.
https://code.visualstudio.com/docs/devcontainers/create-dev-container#_rebuild

[max-sixty]

For the caching — should we mount a volume for ./target? Then it'll be around between restarts...

@richb-hanover if you want to give this a go, it's just another entry here:

prql/.devcontainer/devcontainer.json

Lines 26 to 32 in 4814215

	"mounts": [
	{
	"source": "devcontainer-cargo-cache-${devcontainerId}",
	"target": "/usr/local/cargo/registry",
	"type": "volume"
	}
	],

[richb-hanover]

I see that definition ("target: ... /usr/local/cargo/registry") is already in that file. I assume another { source / target / type} object would need to be added to that mounts array...

Sorry, I'm not really up to speed on Docker/DevContainer tricks. How would we include .target? Thanks.

[max-sixty]

I assume another { source / target / type} object would need to be added to that mounts array...

That's exactly correct! Map a volume to $workspace_root/target (not sure exactly how $workspace_root is represented...)

[eitsupi]

The repository is implicitly bind-mounted. See official documentation.
https://containers.dev/implementors/json_reference/

[max-sixty]

Ah, thanks @eitsupi , sorry for giving bad direction.

It's surprised that rust-analyzer churns away each time, then. @richb-hanover does this happen even without rebuilding the container? Or is this downstream of the issues re rebuilding on mistaken changed files notifications?

[richb-hanover]

You guys are amazing! Just by talking about the problem in this thread, you have caused my computer to act better... No really - it's true.

I had not retrieved any new commits from Github, but now when I start VS Code, I do not see the "Rebuild?" question - it just acts right. rust-analyzer spins for a bunch of seconds (not minutes) and then I can run all the tasks without waiting.

I even retrieved all new commits to make my repo up to date, and it did recompile everything. But after that completed, quitting VS Code and relaunching it didn't give the "Rebuild" message and it only took a few moments to be able to run the second time.

[I'm actually suspicious of this "fix" - I don't know what caused it, and won't be surprised if it crops up again.] But for now, I'm happy. And if it goes south in the future, I'll re-open this issue. Thanks!

Update: If you're really bored, you can watch all the error messages glide by in this (extremely long) video: https://youtu.be/plg7FcXxpVU

[max-sixty]

Just by talking about the problem in this thread, you have caused my computer to act better... No really - it's true.

We aim to please! :)