Can you help me fix this build error for Windows docker?

[sunheat]

Hi team, you might have noticed my other issue with Linux native build. I am trying all tech paths because they each keep on failing for me. This issue is about Windows docker build. Error:

Step 7/9 : RUN powershell.exe -NoLogo -ExecutionPolicy Bypass -Command     "%CURA_BUILD_ENV_WORK_DIR%"\\src\\docker\\windows\\setup_envvars.ps1
 ---> Running in 67abe2cbf9dd
C:\temp\cura-build-environment\\src\\docker\\windows\\setup_envvars.ps1 : The
term 'C:\temp\cura-build-environment\\src\\docker\\windows\\setup_envvars.ps1'
is not recognized as the name of a cmdlet, function, script file, or operable
program. Check the spelling of the name, or if a path was included, verify
that the path is correct and try again.

Where should I check?

I had not tagged my image when I built it, because in cura-build scripts I saw some default name and first time I tried to build a docker image of cbe I chose a different name, so I decided that I would tag the cbe docker using the default name when I figure things out. Apparently I have not figured things out...

[Ghostkeeper]

I don't think the Windows Docker image was really fully developed. It was started as an attempt to change the build system, but not finished when the main carrier of that change left the Cura team.

[sunheat]

I take it as a suggestion for me to switch to Linux (or Linux docker image) as the build system?

And also I think it answers by implication my question on cura-build Issues forum that Linux build env can also produce Windows binaries or binaries which can be encapsulated as Windows EXE's?

Sorry that these are still questions very basic. Besides being new to native builds and Docker, I'm also new to Qt or .AppImage concept lol

[sunheat]

But, regardless of whether that was a suggestion for me to dump Windows build env and switch to Linux or whether I will actually try to do it from Linux or not, do you know if the Windows build env and Windows build scripts for cura-build actually works? I can live with not very well developed, but if it works, I already have a working Windows docker image and I have not had any success with Linux so far. If it does not work, I will surely need to dump Windows and try to fix my Linux build errors.

[evtrados]

Hi @sunheat,

The windows docker flow is now working again. So you can try it once more if you wish. However, note that the problem on Windows is that your host system should be of the same version as your container. We use a Windows Server 2019 VM for our builds, which has a Windows OS version of 1809. So, if you are using a more recent OS version (which I suppose you are) then this will not work for you. Some more information taken from Microsoft's official docker image documentation: "Windows requires the host OS version to match the container OS version. If you want to run a container based on a newer Windows build, make sure you have an equivalent host build. Otherwise, you can use Hyper-V isolation to run older containers on new host builds."

[sunheat]

Hi @sunheat,

The windows docker flow is now working again. So you can try it once more if you wish. However, note that the problem on Windows is that your host system should be of the same version as your container. We use a Windows Server 2019 VM for our builds, which has a Windows OS version of 1809. So, if you are using a more recent OS version (which I suppose you are) then this will not work for you. Some more information taken from Microsoft's official docker image documentation: "Windows requires the host OS version to match the container OS version. If you want to run a container based on a newer Windows build, make sure you have an equivalent host build. Otherwise, you can use Hyper-V isolation to run older containers on new host builds."

Thank you very much for that. I'm going to research how to "use Hyper-V isolation to run older containers on new host builds" to run the Windows docker on my Windows 10 Pro 21H1 host. Do stop me if that is not going to work and I'm going to try and install a Windows Server VM with version 1809

[Ghostkeeper]

Did your build succeed this time?

[sunheat]

I am trying now.

Bought a Nintendo Switch recently so... 🤣

[sunheat]

Did your build succeed this time?

There still seems to be a lot of gaps. For instance, I keep Docker Desktop up-to-date. In options, it does not seem to use Hyper-V as the engine. The option "Use the WSL 2 based engine" is ticked. Should I uncheck that box and let it use "the legacy Hyper-V backend"?

Also I was not bold enough to change the build.ps1 script to replace the docker image with the one I built, it is now downloading ultimaker/cura-build-environment:win1809-latest image and taking a long time. Should I have modified build.ps1 to use my own image which I built, or should I run the image and download cura-build from within the container and use build_in_docker_vs2019.cmd inside the container instead, or will they produce identical results? Which one is working again or are they both working again?

I have also noticed that the "build inside container" batch file had a name change from vs2015 to vs2019. If I want to build from within the docker container, or if it is the best or only working way to do it, does it mean that I have to update the docker image somehow to upgrade its vs2015 to vs2019 (rebuild it maybe)? Or am I better off using a specific tag of cura-build so it still is on vs2015 which would hopefully work better with the cbe image which I built 21 days ago?

Now since the build.ps1 script has already started, I am going to let it finish downloading ultimaker/cura-build-environment:win1809-latest image and see what happens. But I am going to leave it running and go to bed as it is pretty late here in Sydney. I'll see in the morning what it throws at me (probably errors, since I had to fix a few things before I could successfully build my copy of cbe image).

[sunheat]

Download was stuck so I Ctrl+C'ed it. I changed image name to my own cbe build. It is now showing the following in PowerShell ISE execution window.

Mode                 LastWriteTime         Length Name                                                                                                                                                                                                                              
----                 -------------         ------ ----                                                                                                                                                                                                                              
d-----        2021/12/17      1:04                windows-installers

And then it exits with the following error message. The system cannot find the path specified. I'm assuming it is the last line in build.ps1 that failed.

docker run ...
...
powershell.exe -Command cmd /c "C:\cura-build-src\scripts\python3.8\windows\build_in_docker_vs2015.cmd"

But I don't know if it was C:\cura-build-src not exist in the container or it was caused by the name change from build_in_docker_vs2015.cmd to build_in_docker_vs2019.cmd or something else. Thoughts?

I am going to try inside a container tomorrow. But for starting the container, I still need to know whether or not I need to turn off the WSL 2 engine option, and whether I need to start it from command line using specific arguments, like with the Linux image it needs the -it option and specifying the /bin/bash command line environment (sorry for wrong Linux terminology). I am assuming for Windows it is easier, that it is just a matter of clicking the play button in Docker Desktop? Sorry I am using Windows 10 Pro, not Windows Server in command line mode. The image does run and I can open a command prompt from the running container in Docker Desktop. Do stop me if this is the wrong path (shouldn't use WSL 2 engine, or shouldn't run image without certain args, or shouldn't try building inside a container at all, etc. etc.).

[Ghostkeeper]

Should I have modified build.ps1 to use my own image which I built, or should I run the image and download cura-build from within the container and use build_in_docker_vs2019.cmd inside the container instead, or will they produce identical results? Which one is working again or are they both working again?

build_in_docker_vs2019.cmd is a script that will be called by build.ps1 inside of the docker container. You won't need to call it yourself. The downloaded container of cura-build-environment should produce identical results. It is built by this script, after all. It might be binary different because even with containerisation the containers are rarely identical; and might even include some timestamps here and there. But it should be have the same in the end.

Keep in mind that the build environment image is like 14GB and takes several hours to build. Either building it yourself, or downloading it, you have to be a bit patient.

I don't really have experience with Docker on Windows, so I can't help you much with whether you need WSL or whether a graphical application would work. I do know that we've always ran it using a terminal, and our build system runs it from shell scripts (equivalent to using a terminal). So I don't think any of us can answer whether it works okay when you press that play button.