Yes, but where is it? Is it possible to extract it from where it is stored?
Thank you for the confirmation.
So far it is just inside the workspace, and that gets destroyed when the runner is returned to the pool I guess.
So I need to add a step for publishing the release...
I think uploading artifacts is what you should look for. I need to go now, but this was a job really well done, congrats.
Once this is all done and dusted, I think we should give you write access to the Oolite repository so that you can recreate your fork's setup inside it and migrate the github actions to work from within the official repository. There is still the Linux and Mac builds to look at, but I think at least Linux should be doable. Anyway, having the Windows build auto-running again is big news, regardless of what will happen with the other platforms.
I think uploading artifacts is what you should look for. I need to go now, but this was a job really well done, congrats.
Once this is all done and dusted, I think we should give you write access to the Oolite repository so that you can recreate your fork's setup inside it and migrate the github actions to work from within the official repository. There is still the Linux and Mac builds to look at, but I think at least Linux should be doable. Anyway, having the Windows build auto-running again is big news, regardless of what will happen with the other platforms.
Thank you for your assistance. It was a huge motivation to have you onboard.
And I should be going as well but am too exited right now on finishing it up....
Yup, that's great. But you only need to release the installer executable (OoliteInstall-1.91.0.305ad63-dev.exe for this release).
Done. Only the installer gets released. I cannot help having the source code zipped as well - that seems builtin in the release step.
Now we need testers to determine whether that installer has meaningful content.
Opening log for Oolite development version 1.91.0.1-220109-35af706 (x86-64 test release) under Windows 10.0.19044.1415 64-bit at 2022-01-09 22:59:53 +0000.
Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz 8 processors detected. System RAM: 32728 MB (free: 19146 MB).
Build options: OpenAL, new planets, JavaScript console support, OXP verifier, localization tools, debug GraphViz support, JavaScript profiling.
I've been watching this with genuine excitement! Can confirm that it seems to work correctly. As you can see from the log snippets, I have installed twice and both times started a new Jameson, launched, and fired at the buoy to trigger some action. And I took a screenshot as well, but Cody seems to have ninja'd me while I realised I'd forgotten how to host them so that you can see!
Which means we can consider going for Linux and Apple. Similar as with the Windows builds I will need some assistance from someone who has built Oolite on those operating systems before. Who can help?
Which means we can consider going for Linux and Apple. Similar as with the Windows builds I will need some assistance from someone who has built Oolite on those operating systems before. Who can help?
Gentlemen, is this not significant enough to put it out as an official Announcement?
Once this is all done and dusted, I think we should give you write access to the Oolite repository so that you can recreate your fork's setup inside it and migrate the github actions to work from within the official repository. There is still the Linux and Mac builds to look at, but I think at least Linux should be doable. Anyway, having the Windows build auto-running again is big news, regardless of what will happen with the other platforms.
I agree with another_commander we should get the builds running from the official repository. Once that is done I think it is worth the announcement.
@Another_commander: I likely need not only access to the oolite repository but the OoliteProject. After all it is several repositories that need to work together.
@Another_commander: I likely need not only access to the oolite repository but the OoliteProject. After all it is several repositories that need to work together.
I will be sending you an invitation to join OoliteProject soon. I think it might be worth considering importing your changes to the repository only once we confirm that they work though, i.e. start by importing the (already verified) Windows build workflow changes, continue with Mac or Linux once we have confirmation that they work too etc. Note that some further changes will be required for the Windows workflow, as it contains references to your own fork - those should probably be switched over to the Oolite repository.
Anyway, I'll let you handle it as you see fit. Just throwing ideas at this point.
@Another_commander: I likely need not only access to the oolite repository but the OoliteProject. After all it is several repositories that need to work together.
I will be sending you an invitation to join OoliteProject soon. I think it might be worth considering importing your changes to the repository only once we confirm that they work though, i.e. start by importing the (already verified) Windows build workflow changes, continue with Mac or Linux once we have confirmation that they work too etc. Note that some further changes will be required for the Windows workflow, as it contains references to your own fork - those should probably be switched over to the Oolite repository.
Anyway, I'll let you handle it as you see fit. Just throwing ideas at this point.
If you prefer I can run pull requests. But https://github.com/HiranChaudhuri/oolit ... -build-env does not yet exist in OoliteProject. And it is no longer the pure zip you sent to me. Just check it's history. That should be the only reference to my own fork. I had to change oolite/.gitmodules to contain absolute URLs to not refer to my own fork.
I believe your Windows build workflow references also your own oolite repository for downloading the code, so I guess this will have to be changed to point to the official repo. I could be wrong though, but in any case all these are things that can be adjusted further down the road.
Regarding the dev environment, I would suggest removing the folders Mingw32_100300, Mingw64_100300, mingw32_710 and mingw64_710. They add huge volume to the data the workflow tries to download and they are not used at all.
