Initial release of release tools

[jdarwood007]

These are proposed tools to change the release process for SMF 3.0.

Building with this tool does not generate the same hashes as the tools currently used to build SMF releases. Those tools use the GNU zip/tar executables. This script is using PHP Phar, and it appears to do something different in the generation of the archives, which I can't see why it is different.

I verified the SHA256 of the files inside matched via:

# Building a hash list from a current download
mtree -c -K sha256digest -k sha256digest -p smf_2-1-6_install > base

# Validate hash list
mtree -p test/smf_2-1-6_install < base || echo fail

I yielded no results after a few corrections. I think we may end up having to accept that we won't be able to generate binary identical setups unless we really want to dive into the archiving process for phar.

This also includes a tool to build the patch file. I kept in mind that 3.0 will be able to use a diff file and build that. But also built in the support to convert the diff into an XML file, so we can use this tool on 2.1 if we wish.

The final tool is one to build language packs. The language tool does require the Crowdin API to work. For testing, you can generate a personal access token on Crowdin. I generated mine with read-only only to everything except translations, I had to grant it read/write to trigger a build.

I tried to ensure this tool will cross build, but it will exist in both the 3.0 and 2.1 branches for future simplicity.

[live627]

Why shoehorn all this into a php script? Wouldn't a shell script be a better fit? Example: Shell script calls php script and then tar and zip files.

[jdarwood007]

For ease of running it in other scripts to generate all the files we need.

I don't know if running the script we use to make official builds would generate the same hash, given a complete rebuild of the git repo it works with. I started to suspect that the hashes may not match because the tar/zip process is handling metadata like file modification time, which may not reflect the time it was modified.

[jdarwood007]

In more research over my answers to why the hash won't match, I found this bug report: https://bugs.php.net/bug.php?id=77229
They are not storing the proper time. I suspected as such that some metadata was different, as I can validate the archives, the tool was 100% matching. I even used another tool called pkgdiff to validate that they were 100% identical.

We can also use compression streams. https://www.php.net/manual/en/wrappers.compression.php
We can also use system calls to the GNU libraries, but this limits its ability cross cross-system workability to find the executables for tar/zip.

Honestly, I am fine with it since the internal contents are the same.

[live627]

Ah ok so we want portability, too. You can use the code I wrote, specifically, writeTgzFile

• Faster package backup creation SMF#8430

That bug report linked to above is just another reason to move away from PharData. Too many unexpected behaviors for working with general archival and compression files.

[jdarwood007]

That looks promising, but I see we would need it to write bz2 and zip files. It would also need to exclude the uid/gid as we don't care for those.

[live627]

I have a self contained patch building script https://github.com/live627/SMF2.1/blob/linttest/bootstrap.php Feeel free too use any of the code therein

Invoked via CLI https://github.com/live627/SMF2.1/blob/linttest/.github/workflows/create-patch.yml

[jdarwood007]

I had to rework some of the logic. A few file deletions are occurring here for the upcoming 2.1.7 patch. The best option was to save those as a file so we could use the remove-file operation instead of emptying the file. We can't delete the file during patch operations; only the info file can be deleted.