CI workflow QoL improvements

[ThreeDeeJay]

As discussed in #52 (comment), here are some changes I had proposed, plus some QoL improvements and fixes:

• Include full commit hash in Version.txt files
• Include commit title in release description and Version.txt files (might wanna avoid unescaped special characters like quotes)
• Improve compression with nested zip files (uncompressed zip inside a max compressed zip) to work around its lack of solid compression, for compression ratio comparable to 7-zip, ~1/3 of regular zip, 1/6 of the uncompressed files, while still maintaining backwards compatibility with systems that can't extract 7z files out of the box. This could allow adding more pre-configured builds with negligible filesize increase.
• Replace all third-party actions with standard commands. Only action left is the official artifact upload since there's no way to upload artifacts via the CLI like we can download them
• Fix tagged release using tag instead of branch name by hardcoding the master branch, since GitHub made it ridiculously hard to get the current commit's branch when the workflow has been triggered by a tag.
• Fix infinite loop that triggers a new build when creating a release tag by making the untagged workflow trigger ignore all tags (including, e.g.: r123, created upon release), not just ..*

Additional notes:

• DSOAL still gets rebuilt daily and they're labeled as Scheduled in the Actions page so that the latest build always has a recent OpenAL Soft. I think it's possible to trigger a new build upon OALS commits, but it requires some advanced webhooks on both repos that I haven't quite gotten my head around to.
• Since every workflow run releases both a r### and latest-branch tags, daily builds will overwrite the previous one. e.g.: the original r647 may not the the same as r647 from a few days later if OpenAL Soft was updated in the meantime. But at least now we know the version for each file in the Version.txt and log.
• If you want to release a stable build, you only gotta add a semver (*.*.*) tag to a commit and push it. That'll trigger a stable build that uses the last stable OpenAL Soft, so it might be a good idea to create it shortly after a stable OALS release 👀👌

So e.g.:
https://github.com/ThreeDeeJay/dsoal/releases/tag/r648 - Triggered by new commits and daily schedule, may get overwritten
https://github.com/ThreeDeeJay/dsoal/releases/tag/latest-master - Same as above, except it always gets overwritten
https://github.com/ThreeDeeJay/dsoal/releases/tag/0.9.8 - Triggered by manually pushing a *.*.* tag, never gets overwritten (unless the tag gets re-assigned to another commit?)

[kcat]

Include commit title in release description and Version.txt files (might wanna avoid unescaped special characters like quotes)

This could be an issue, I can't guarantee I won't inadvertently use "special" characters it may not like.

[ThreeDeeJay]

Fair enough. tbh I'm not too familiar with Linux commands so would you happen to know how to properly escape special (or all?) characters of the output of git show --pretty=format:%s -s HEAD after checking out a commit like 59f0933?
I had tried some regex/string replacement but the best I could do was escaping all characters but they would still show up on the final message string so I just commented it out since I'm not sure what I'm missing https://github.com/ThreeDeeJay/dsoal/blob/9271ee1005ddf955136203275c7bd43feb9c7a2d/.github/workflows/build-all.yaml#L62

[kcat]

Fair enough. tbh I'm not too familiar with Linux commands so would you happen to know how to properly escape special (or all?) characters of the output of git show --pretty=format:%s -s HEAD after checking out a commit like 59f0933?

Have you checked and seen problems when you do? As far as the commands themselves go, the echoes seem to work fine:

$ echo "DSOALCommitTitle=$(git show --pretty=format:%s -s 59f093346ac10397ecac14239f557e2119391cbd)"
DSOALCommitTitle=Don't check the dataflow for non-null GUIDs
$ export DSOALCommitTitle=$(git show --pretty=format:%s -s 59f093346ac10397ecac14239f557e2119391cbd)
$ echo "${DSOALCommitTitle}"
Don't check the dataflow for non-null GUIDs

They're not getting interpreted as escape characters for the commands, at least on my machine. Though I'm unfamiliar with $env:GITHUB_ENV and how that may interact with special characters.

[ThreeDeeJay]

Huh, either they fixed special characters breaking variables or it only breaks in certain cases (release titles?), because the commit title looks fine on this release description and in DSOAL-Version.txt.
I can't check the original commit errors because the logs expired but I remember trying to figure it out and now it's just... magically fixed? Amazing.

By the way, apparently they may have also fixed the issue where gh CLI commands failed to create releases without a personal token added as a repo secret, so I replaced it with a regular Github token. If it causes issues, you might need to revert c3d52e8 and add a personal TOKEN with write permissions to the repo's secrets.

Oh, and one more thing:
Creating a release that already exists would fail (e.g. updating the latest tag release).
So I manually delete the release with its tag before creating a new one. But if the release doesn't exist (e.g. creating a new r### tag that had never been created) it returns error code 1, adding an error to the workflow run annotations. So I just appended || true to make sure it always returns error code 0 and is treated as a success to prevent the annotation error.

Anyhow, I think this should now be ready to merge 👀🤞

[kcat]

Actually, I think I noticed a bit of a problem (not necessarily from this PR, probably the last one). It seems every push to create a new archive/package also creates a new tag. I just pulled from the repo to sync my local branch and was greeted by

From github.com:kcat/dsoal
   8bf53ca..2978c47  master        -> github/master
 * [new tag]         latest-master -> latest-master
 * [new tag]         r607          -> r607
 * [new tag]         r608          -> r608
 * [new tag]         r615          -> r615
 * [new tag]         r618          -> r618
 * [new tag]         r624          -> r624
 * [new tag]         r625          -> r625
 * [new tag]         r626          -> r626
 * [new tag]         r629          -> r629
 * [new tag]         r633          -> r633
 * [new tag]         r635          -> r635
 * [new tag]         r637          -> r637
 * [new tag]         r639          -> r639
 * [new tag]         r641          -> r641
 * [new tag]         r647          -> r647

which seem pointless and redundant since there's not many commits in between each one, and anyone else pulling will also be greeted with more new tags each time there's been updates. Is there some way to stop this?

[ThreeDeeJay]

Yeah, the workflow creates a tag for every (pre-/)release since it's required by GitHub. That way users can track down possible regressions from a trusted and permanent source, since builds uploaded to the workflow as artifacts expire after 3 months.

With that in mind, creating new tags upon release can be disabled if you'd rather just reuse the latest tag like in OpenAL Soft, so let me know and I can submit another PR for it 👀👌

[ThreeDeeJay]

Come to think of it, I might be able to just upload each new DSOAL_r###.zip file into a single release/tag.
That way we'd still have permanent download without needing extra tags 🤔
So I imagine it wouldn't make a lot of sense to use latest, but what should be used instead? old? archive? history? legacy?

[ThreeDeeJay]

#114

[ThreeDeeJay]

@kcat we might have an issue here: ThreeDeeJay#6
tl;dr Apparently Windows explorer lacks LZMA supports so it fails to extract the current Zip format.
ThreeDeeJay@ccc4d07 fixed it here but it makes the filesize ~3x bigger (potentially more if we ever add more pre-configured folders with duplicate files). 7-zip and WinRAR have no issues either way, but the point of nested Zip instead of 7z was backwards compatibility, which may not be so compatible after all. 😅