[Bug]: Docker compose ignores new message type and uses old image from cache

una-auxme / paf

Praktikum Autonomes Fahren - PAF

MIT License

9 stars 0 forks source link

[Bug]: Docker compose ignores new message type and uses old image from cache #542

Open seefelke opened 1 week ago

seefelke commented 1 week ago

Current Behavior

When you implement a new message type the docker compose ignores the changes and proceeds to just use the old cached image. Manually running catkin_make makes the message type available in attached VS code but still crashes the node when trying to use it. A current workaround is to delete the build-agent-dev image from cache and fully rebuild it.

Expected Behavior

No response

Steps to Reproduce

When you try to use one of the new message types like planning/Trajectory the node will crash. In attached VSCode the new types will also not be visible in the environment without manually using catkin_make.

Definition of Done

The docker compose properly builds catkin when a new message type is implemented. The new message type is then available to use without crashes.

Testability

No response

Dependencies

No response

vinzenzm commented 1 week ago

Glad you openend an issue on this: When implementing the visualization for the intermediate Layer I also stumbled over probably the same issue: https://github.com/una-auxme/paf/issues/517#issuecomment-2495700215

However I dont remember having a similar issue when working on the manual steering panel (#419). However I am not 100% sure.

I compared the dev-branch for #419 with current main and I dont see any changes which could explain this behaviour. The only changes that happened in the launch routine were due to the debugger. However I dont see any Problem with them. (This link compares the current version with the old one: https://github.com/una-auxme/paf/compare/7edac9d120777744023958505a10ae3fefb1adeb...main)

@Zelberor I know you are currently also implementing a new message type so this issue is interesting to you as well. Maybe you also have a differnt view on the changes performed for the debugger.

It might also be that the vscode task I implemented in https://github.com/una-auxme/paf/pull/497 does not work the way I intended it to? @seefelke Did you use the task for executing catkin_make or did you open a shell?

seefelke commented 1 week ago

@vinzenzm I executed it inside a shell.

Zelberor commented 6 days ago

@seefelke if you run catkin_make manually, the command has to be executed in both the build-agent (that's the leaderboard) and the build-agent-dev (that's just for vscode, nothing else runs in it) containers. Did you run it in both?

But generally speaking that update process for the docker configuration is currently very cumbersome. I have a solution in mind and will probably try to implement it on monday. That would include:

Moving all user related stuff out of the dockerfile into a initialization routine that is executed at the start of the container. This includes the pip installation and catkin_make
Only running this init on the first start of the container. When wanting to update/rebuild, the user then can easily use docker-compose down to delete the container and then start them to trigger a rerun of pip and catkin.
It also would allow to upload the container images into the registry, because they will be the same for all pcs

@vinzenzm Any remarks on this?

seefelke commented 6 days ago

@Zelberor Ah I see, I only executed it inside build-agent-dev.