I'm so confused about the Rider dockerfile, docker compose workflow - fast and not fast

I'm quite confused about the intended edit-compile-run-test workflow that I'm supposed to be using with Rider and dockerfiles.  I feel like I'm not effiecient and am going against the grain in how I am using the tool, but the documentation really isn't helping.

I have a solution with several projects.  One of which is a .Net web application that I want to build as a Docker image that will ultimately ship to production (but in that case, Jenkins will build the Dockerfile and manage pushing to our repo).    

I would like a rapid way to build this Dockerfile, and run the image locally so that I can execute integration tests against it.  

The Dockerfile is a multistage build, that uses the SDK and Runtime ASPNet images from MS. Although our “final” layer is customized and uses our own ENTRYPOINT “startup.sh” as well as a few other final layer customizations.  We also have some buildargs that we invoke the build with.

In order to run the image, there are multiple property, volume and network declarations.

To make both building and running the image easier, we have been using a docker-compose.yml to capture all of the above.  This mkes it as simple as “docker compose build; docker compose up” for us.  

However that is a very slow edit-compile-run-test turn around and I want to use whatever features Rider exposes to improve this

Reading about Fast mode, seems like what I need:  I want to CTRL-B my web app project in the IDE and have those files instantly available in my image and run it.   Ideally I'd like the dotnet process running in the container to hot reload.

Based on my compile and run constraints above here is what I am doing:

- Since our multi-stage build is slow, and the “base” layer does not have the customizations that I need to run my application, I have created a “Dockerfile.localdev” that only contains one stage with predefined ENV customizations in place: It derives from the MS runtime image and does not have an ENTRYPOINT as I believe that is predefined by Fast Build

I can CTRL-ALT-F5 on this Dockerfile and it will start to run - but I had to put quite a few customizations into the associated Run Configuration, including the bind ports, networks etc… all stuff that belongs in a compose file.  I did have to recreate the Run Configuration on more than one occassion due to running “git clean” in my workspace and losing all the Rider configuration that was not added to the repo.

With this basic setup, edit, build, run and test is faster (albeit needs quite a few key presses to get from the editor window to a running updated container).  I would think that I could make this even faster if I could figure out how to get “dotnet watch run” to work in this situation - then I would only need CTRL-B to build the project and the process should detect the DLL change and reload.

Unforunately in this case, it's not clear to me when the actual image is rebuilt - so if I change the Dockerfile, I'm not confident that a new image is built and a new container is started.  THere is no option in the project explorer gui to force a rebuild of the image. (or none that I can see)  (I've just found a “Build Image For xxx” option on the drop-down of the double arrow in the margin of the Dockerfile…  I'm wondering how to control tags and buildargs for that?

My project then got a little more complicated.  I needed a second docker application that I want to run when doing local integrations tests - this acts as a mock for one of our third party services.

THe obvious way to manage these is with a docker-compose.yml: the services have a start-up dependency, and they also need to be on same networks and have combinations of properties that are all best managed in compose: Run Configurations are just unneeded compllexity.

I can CTRL-ALT-F5 on the compose file and it will “compose up”.  But I have no confidence that it is rebuilding the image when I change the Dockerfile.  There is no option to “compose build”.  If I build the Dockerfile directly, I get an untagged image that is not what the compose file loads.  I don't know how Fast Build is working with this.

I'm going in circles and this message is longer than I intended - most likely I'm shouting into a blackhole.

I'm happy to pursue any other “flows” / suggestions to get a smoother development cycle  (for me and my colleagues who seem to have become numb to the friction)

Pete