Impact of new builds

[hiran]

Now that we have the new builds (msix, appimage, flatpak) it is much easier to distribute Oolite again. In parallel the MacOS build was removed - it did not work anyway on today's Apple computers. Kudos for those who worked hard to get there!

At the moment when Oolite 1.92 was released and the 'latest' tag moved from 1.90, there was some impact that most of us missed to notice: The process to index all the Oolite resources failed. The result of this indexing is the Oolite Expansion catalog (source here, result here). It is this catalog that allows both the builtin Expansion Manager and the external OoliteStarter to offer OXPs for download and manage dependencies.

"Why did it fail?" you may ask. To have a complete index also the Oolite builtin resources get indexed - they are visible at Oolite 1.92. "But apparently it worked!" you should say now. Well, the builtin resources are zero ships, zero equipment and zero models.

Someone created a file called Oolite-1.92.zip with some content to keep the indexing going. But this file was created and added manually. This is a bad pattern since if can be forgotten again, or the content of the file may get wrongly packaged. Indeed it deviates from what we used to have. Therefore I'd like to see that wound spot get improved.

It is not easily possible to unpack resources from msix, appimage or flatpak builds. Also it is not possible to just read the content from Source.zip for two reasons:
- The manifest.plist is just created during build so it has the real version number inside
- Some resources are outsourced into the binary resources repository that also is not part of Source.zip.

Let's extend the build scripts to provide Oolite resources as zip file. It does not have to be a complete distribution, but it helps for further automation.

[mcarans]

Now that we have the new builds (msix, appimage, flatpak) it is much easier to distribute Oolite again. In parallel the MacOS build was removed - it did not work anyway on today's Apple computers. Kudos for those who worked hard to get there!

At the moment when Oolite 1.92 was released and the 'latest' tag moved from 1.90, there was some impact that most of us missed to notice: The process to index all the Oolite resources failed. The result of this indexing is the Oolite Expansion catalog (source here, result here). It is this catalog that allows both the builtin Expansion Manager and the external OoliteStarter to offer OXPs for download and manage dependencies.

"Why did it fail?" you may ask. To have a complete index also the Oolite builtin resources get indexed - they are visible at Oolite 1.92. "But apparently it worked!" you should say now. Well, the builtin resources are zero ships, zero equipment and zero models.

Someone created a file called Oolite-1.92.zip with some content to keep the indexing going. But this file was created and added manually. This is a bad pattern since if can be forgotten again, or the content of the file may get wrongly packaged. Indeed it deviates from what we used to have. Therefore I'd like to see that wound spot get improved.

It is not easily possible to unpack resources from msix, appimage or flatpak builds. Also it is not possible to just read the content from Source.zip for two reasons:
- The manifest.plist is just created during build so it has the real version number inside
- Some resources are outsourced into the binary resources repository that also is not part of Source.zip.

Let's extend the build scripts to provide Oolite resources as zip file. It does not have to be a complete distribution, but it helps for further automation.

Thanks for checking this. Lone_Wolf mentioned adding a source.zip that contains not just the oolite repo but all the deps as well for distro package creators. Would that help here?

I'm not clear how the expansion process works. Is the process this GitHub workflow: https://github.com/OoliteProject/oolite ... /Build.yml? Or one or more these workflows https://github.com/OoliteProject/Oolite ... er/actions? Or all or some of the above?

How do they interact with the main Oolite repository ie. what do they expect it to have and where do they expect it to be?

[hiran]

Thanks for checking this. Lone_Wolf mentioned adding a source.zip that contains not just the oolite repo but all the deps as well for distro package creators. Would that help here?

I'm not clear how the expansion process works. Is the process this GitHub workflow: https://github.com/OoliteProject/oolite ... /Build.yml? Or one or more these workflows https://github.com/OoliteProject/Oolite ... er/actions? Or all or some of the above?

How do they interact with the main Oolite repository ie. what do they expect it to have and where do they expect it to be?

You already identified the components.

OoliteAddonScanner is the tool that reads a list of URLs, downloads the stuff it finds and generates the summary. Output is the catalog for the expansion managers and a bunch of html files.

The second Github actions script you found compiles tOoliteAddonScanner's Java code, runs the tests and eventually provides a release.

The first workflow you identified uses the release of OoliteAddonScanner and executes it. It is triggered whenever the list of URLs change plus once a month (just in case the OXPs change although they remain on the same URL).

I created this toolchain when the old website was lost, and with it a mysql db and php frontend. The process relied on the Oolite zip distribution to read Oolite resources. Version 1.90 was official and available during all this time which has changed now. So now I need an alternative to access the ressources folder of an Oolite installation.

I saw and acknowledge Lone Wolf's comment about Sizrce.zip but I am not talking about recompiling Oolite again. If we just had a distribution without installer, or even just the resources folder it would be fine already.

There is little effort in getting such a distribution. When buildint Oolite the files accumulate on the build server anyway. Just zip them up before triggering msix/appimage/flatpak flows and publish it as assets.

One of the use cases for the zip is the indexer. Another would be to quickly inspect the content of a build if you do not want to analyze the packaging format.

Have a look at https://tooomm.github.io/github-release ... iteStarter
I am surprised about the download counts of the zip and tar balls although other packaging formats are offered.

The same analysis can be done for Oolite at https://tooomm.github.io/github-release ... ory=Oolite
Just scroll enough to see the Oolite 1.90 downloads.

[another_commander]

The Windows installers are lzma compressed files although they are executables at the same time. Can you treat any of them as an lzma (7zip opens them fine as an example) to get access to Resources?

[hiran]

The Windows installers are lzma compressed files although they are executables at the same time. Can you treat any of them as an lzma (7zip opens them fine as an example) to get access to Resources?

OoliteAddonScanner does not invoke 7zip. I can test if it can be read as zip file.

It's not me who wrote the above quote. hiran you may have mis-edited your response.

Indeed I misedited unintentionally. I'm sorry for that and hope to have restored the original post.