I am thinking about how to simplify the build so that new developers can understand it easily. I'm also considering how to have the version come from the GitHub release tag into the build rather than having to be hard coded in different places. So I need to get an understanding of what is being used and how.
I am striving for the same and thus open to discuss. The Github flows you improved were introduced by me to relieve developers from building manually on different platforms. However currently there is impact.
Could we restore functionality and then discuss how to simplify?
I am preparing a zipped 1.92 source code tarball and am going to add the manifest file (the one normally created during build) inside it. Resources will be included too. Hopefully this will help with the issue.
I am preparing a zipped 1.92 source code tarball and am going to add the manifest file (the one normally created during build) inside it. Resources will be included too. Hopefully this will help with the issue.
Hiran, is that enough to create the expansion catalog from ?
That's what I was asking for, yes. It does not prevent that I have to make adaptions as the structure is not identical to the MacOS build I had used before - but that is no showstopper.
I'd like the file to be autogenerated so we can be sure it always exists and has the same structure. The name of the file is not important either - but calling it source would imply it is a dump of the repository where some of the content is not part of the repo. From my desk this looks misleading. But as said, it's not that important.
I downloaded and inspected the new file oolite-1.92.zip. It contains the required files. It also contains traces of having been handcrafted.
With the oolite-1.90.zip I used to processed the path /Oolite.app/Contents/Resources/
With the oolite-1.92.zip I now need to process the path /oolite.app/Contents/Resources/
As the indexing runs on a Linux build machine the case matters. I would need to know whether this is a typo that will be corrected or if it is the future directory structure and thus the indexing process needs to access the new location.
And such little differences are what can break automation completly - the reason why I'd like to have this new file produced by the build process automatically.
The source code zip is just a zipped up full git checkout of the oolite repository at the 1.92 tag, including all submodules. The manual interventions are the deletion of the .git folder (not needed for the purposes of this zip) and the addition of the manifest file in the Resources folder. Everything else is exactly as it currently stands in github.
I would suggest using the 1.92 source zip as reference. There are no typos there, it is what's in the source at this moment.
Both of them claim to have been created with a minimum effort. And the structure differs enough that I would not know which one to take as authorative.
Both of them claim to have been created with a minimum effort. And the structure differs enough that I would not know which one to take as authorative.
The first one was created by phkb as a quick and dirty solution to allow for the expansions indexing mechanism to work again. I have not downloaded it but I can imagine it was based on the previous Mac binaries' structure.
The second one is an actual source code dump. Since we do not have Mac builds anymore, this is the one that should be taken as authoritative.
Both of them claim to have been created with a minimum effort. And the structure differs enough that I would not know which one to take as authorative.
The first one was created by phkb as a quick and dirty solution to allow for the expansions indexing mechanism to work again. I have not downloaded it but I can imagine it was based on the previous Mac binaries' structure.
The second one is an actual source code dump. Since we do not have Mac builds anymore, this is the one that should be taken as authoritative.
I just downloaded the second file again. Has it changed? Nevertheless, now it matches the structure I get when executing the above statements.
With that I can change OoliteAddonScanner to download such files and access the correct path. We just need to ensure that future builds also provide that zip.
I just downloaded the second file again. Has it changed?
No, it was uploaded only once and not changed since.
Nevertheless, now it matches the structure I get when executing the above statements.
With that I can change OoliteAddonScanner to download such files and access the correct path. We just need to ensure that future builds also provide that zip.
Please let us know when you have adjusted the OAS to use the new paths so that we can remove the Oolite-1.92.zip file from the release.
Great news! One less file in the releases simplifies it a bit.
If we are able in future to move to a monorepo instead of Git submodules, then presumably the auto generated "Source code (zip)" will be the same as "oolite-source-*.zip" file so the latter won't be needed?
If we are able in future to move to a monorepo instead of Git submodules, then presumably the auto generated "Source code (zip)" will be the same as "oolite-source-*.zip" file so the latter won't be needed?
I agree. Since we do not have a monorepo, how can we make sure the "Source code (zip)" in future versions will contain what the one for v1.92 does?
If we are able in future to move to a monorepo instead of Git submodules, then presumably the auto generated "Source code (zip)" will be the same as "oolite-source-*.zip" file so the latter won't be needed?
I agree. Since we do not have a monorepo, how can we make sure the "Source code (zip)" in future versions will contain what the one for v1.92 does?
According to AI "What IS included (in Source code (zip))
All tracked files: Every file and folder currently committed to the repository at that specific tag/commit.
The directory structure: The folder hierarchy is preserved exactly as it appears in your main or master branch.
License and README: These are included just like any other source file."
To make the move to a monorepo, we should first delete any binaries that are no longer required by the modern builds. Then it's a just a case of making directories corresponding to the same locations as the pruned submodules. The biggest submodule is probably Resources/Binary at around 115Mb (according to AI) so this process won't add a lot to the Oolite repo by today's standards.
Actually there is one earlier step that would be advisable - for the Windows build to become modern only and drop the legacy build otherwise the old dlls and all espeak data will need to be checked into the Oolite repo.
If we are able in future to move to a monorepo instead of Git submodules, then presumably the auto generated "Source code (zip)" will be the same as "oolite-source-*.zip" file so the latter won't be needed?
I agree. Since we do not have a monorepo, how can we make sure the "Source code (zip)" in future versions will contain what the one for v1.92 does?
According to AI "What IS included (in Source code (zip))
All tracked files: Every file and folder currently committed to the repository at that specific tag/commit.
The directory structure: The folder hierarchy is preserved exactly as it appears in your main or master branch.
License and README: These are included just like any other source file."
To make the move to a monorepo, we should [...]
I'm afraid I am not there yet. My worry is that by the next release of Oolite we forgot a manually added oolite-source.zip is required and we will start over this discussion.
Let's have the github workflow automatically create that file. AFAIK it is the repo content including submodules bar one file. Your AI agent neglected that part. Thus Github's automatically generated Source.zip will never deliver the required file.
