Generate embeddings within the docker build stage "build" to allow building images on machines without dotnet

[vijaygill]

This issue (and the PR I am going to raise) will improve the following:

1. This allows the build.sh to be run on the machines which do not have dotnet installed. Like my RK3588 based NAS. I run all my MCP servers there so I can access them all from my main machine / laptop / anywhere else.
2. Generates image for ARM64 if build.sh is run on am ARM64 machine. I am already running it after building the image.

PS: I have not tested the Azure side as I do not have subscription.

This screenshot proves that build is successful on my Orange Pi 5+.

Screenshot showing the MCP server added to VSCode

Screenshot to show CSLA-MCP server responding to initial starting by VSCode

[vijaygill]

@rockfordlhotka - If you are OK for this change, I will make more changes to allow the user to pass those Azure related variables to docker (as build-args).
And I will update the README.md also to reflect the changes to build process.

[rockfordlhotka]

@vijaygill you decided not to move forward with this idea?

[vijaygill]

@vijaygill you decided not to move forward with this idea?

@rockfordlhotka I really want to. But I got cold feet at the end. Didn't want to mess with something nice you have there.
But I still have it iny fork.
I also planning to use other options of generating embeddings ( I am reading up on those Smart controls local embeddings).
If you are ok with this idea, I will be glad to contribute.
Thanks for looking at this ticket though.

[rockfordlhotka]

The idea of being able to build the image without needing .NET SDK on the host makes sense to me.

I think the only reason for needing .NET on the build host is to run the code that vectorizes the markdown files before building the container image right? So if the vectorization was inside the container build process it would accomplish the same goal.

The only thing that I know I do, is when I'm working on the code itself is to not run the vectorization step over and over again, because unless I change markdown files I can use the cached json file with the vectors.

[vijaygill]

The idea of being able to build the image without needing .NET SDK on the host makes sense to me.

I think the only reason for needing .NET on the build host is to run the code that vectorizes the markdown files before building the container image right? So if the vectorization was inside the container build process it would accomplish the same goal.

The only thing that I know I do, is when I'm working on the code itself is to not run the vectorization step over and over again, because unless I change markdown files I can use the cached json file with the vectors.

That's a fair scenario too. Let me think a bit more about this. In multi-stage builds, the layers are cached. So if nothing has changed in the markdown files, the cached layer would help in faster build over and over again.

Let me use the the old technology of pen and paper (I am more of a pen and paper guy TBH) and see how I can get this working to suit both scenarios - generate embeddings / skip generating embeddings.