I think the environment does run, but we don't get to see its output. Probably the build fails at some point and therefore no resulting artifact files are generated. Not sure what to do here, I'm afraid.
The only suggestion I have at this poibt is to remove the path:oolite line from the Checkout Oolite job. It seems to result in the subnodules getting installed in D:\a\oolite\oolite\oolite, which is not right (they should go in D:\a\oolite\oolite, like everything else). Maybe this is why the build might be failing. Give it a try.
###### Oolite changes start ######
echo "Environment variables:"
env | sort
echo "Current working directory:"
pwd
if [ ! -z "$GITHUB_WORKFLOW" ]; then
echo "We are in Github. Let's build the project.
cd "$GITHUB_WORKSPACE"
make -fMakefile pkg-win-snapshot
fi
###### Oolite changes end ######
So I'd at the very least would expect the environment variables and the current working directory to be printed. But as we see there is nothing. Not even an exit code !=0.
You are probably right about the location of the checkouts. As for msys: the windows runner executes cmd.exe and that in turn calls msys, but I am not sure whether the msys messages are supposed to be redirected to the output of the github runner or not. Msys is basically a bash shell and I am not certain about the details of how it handles its input and output streams. Given how short the overall running time of the workflow is, it may be entirely possible that msys does not run at all though. At this point, I have no idea why.
You are probably right about the location of the checkouts. As for msys: the windows runner executes cmd.exe and that in turn calls msys, but I am not sure whether the msys messages are supposed to be redirected to the output of the github runner or not. Msys is basically a bash shell and I am not certain about the details of how it handles its input and output streams. Given how short the overall running time of the workflow is, it may be entirely possible that msys does not run at all though. At this point, I have no idea why.
Seems we need to go in little steps and even consider a .bat file to be outdated.
You are probably right about the location of the checkouts. As for msys: the windows runner executes cmd.exe and that in turn calls msys, but I am not sure whether the msys messages are supposed to be redirected to the output of the github runner or not. Msys is basically a bash shell and I am not certain about the details of how it handles its input and output streams. Given how short the overall running time of the workflow is, it may be entirely possible that msys does not run at all though. At this point, I have no idea why.
Some small progress. I created a minimal cmd script, and it seems the workflow gets to call that. Finally!
I found a potential issue with the dev environment. I was under the impression that it was location agnostic, but it looks like there are some hard-coded paths in it in the etc/fstab file. Apparently the location-agnostic version is the Dev Env Light Edition one which I had distributed in the past, but that version does not have installer creation capability.
Just to be safe, I think it would be a good idea to ensure that path references agree between the folder where the dev environment is installed during the github action runs and the fstab file. The etc/fstab file should read
I found a potential issue with the dev environment. I was under the impression that it was location agnostic, but it looks like there are some hard-coded paths in it in the etc/fstab file. Apparently the location-agnostic version is the Dev Env Light Edition one which I had distributed in the past, but that version does not have installer creation capability.
Just to be safe, I think it would be a good idea to ensure that path references agree between the folder where the dev environment is installed during the github action runs and the fstab file. The etc/fstab file should read
Is that a snippet or the full file? I think we can make the oolite build-windows.yml workflow write those settings. Ah, seeing the current version this is definitely a snippet. We could also continue the drive mapping pattern:
O: points to Oolite
T: points to the toolchain/development environment
Another thing I figured out using the cmd script: This line is problematic as it triggers a process in a separate window, then terminates. I'd change start into a call?
Not sure how the github runners would behave if you try to map a new drive (o:) as part of the build process. There could be permission issues involved, but sure, if you want to try it give it a go. The snippet I posted is essentially the entire fstab file, since all the rest of the lines contained within the original fstab are either comments (begin with #) or refer to SVN, which was the source control we had back in the early 2010s.
Try to change start to a call. Hopefully it will help.
Not sure how the github runners would behave if you try to map a new drive (o:) as part of the build process. There could be permission issues involved, but sure, if you want to try it give it a go. The snippet I posted is essentially the entire fstab file, since all the rest of the lines contained within the original fstab are either comments (begin with #) or refer to SVN, which was the source control we had back in the early 2010s.
h: /etc/profile: line 75: unexpected EOF while looking for matching `"'
sh: /etc/profile: line 80: syntax error: unexpected end of file
]0;MINGW32:~
runneradmin@fv-az82-541 ~
$ logout
Current working directory:
/home/runneradmin
D:\a\oolite\oolite>exit
Current working directory:
/home/runneradmin
We are in Github. Let's build the project.
make: Makefile: No such file or directory
make: *** No rule to make target `Makefile'. Stop.
]0;MINGW32:/d/a/oolite/oolite
Once that is done I may need your help to identify a meaningful build, and what to publish as a release.
The 'check filesystem' step lists everything recursively and creates about 16 MB of output. The browser gui does not display it all, but the logs can be downloaded and evaluated in full.
Last edited by hiran on Sun Jan 09, 2022 10:06 pm, edited 1 time in total.
Once that is done I may need your help to identify a meaningful build, and what to publish as a release.
The 'check filesystem' step lists everything recursively and creates about 1.6 MB of output. The browser gui does not display it all, but the logs can be downloaded and evaluated in full.
Oh, I've seen NSIS (it's been a long time) and this:
