In the days right before publishing the GA Zui v1.3.0 release, I realized that Zui Insiders releases had not been getting published for a while. A peek at a recent attempted release seemed to show what was going on: The "Check If Release Is Needed" seemed to be finding tag 1.2.1-9 as the "latest" even though 1.2.1-10 had been published for weeks. The "Build Zui" would therefore proceed as if it was building 1.2.1-10, then it would bail on actually uploading any artifacts, saying:

  • GitHub release not created  reason=existing release published more than 2 hours ago tag=v1.2.1-10 version=1.2.1-10 date=Tue Aug 29 2023 03:27:05 GMT+0000 (Coordinated Universal Time)
  • skipped publishing  file=zui-insiders_1.2.1-10_amd64.deb reason=existing release published more than 2 hours ago tag=v1.2.1-10 version=1.2.1-10 date=Tue Aug 29 2023 03:27:05 GMT+0000 (Coordinated Universal Time)

Before the Monorepo changes #2818, Insiders builds were triggered from within the Zui Insiders repo itself, and the logic was simpler such that it always triggered a build with a new version tag every weekday even if nothing had changed in the repo. But as part of the Monorepo changes and Insiders build now being triggered from within the main Zui repo, new logic was introduced to only trigger builds when there were changes, and part of this logic included using an Action to find the build SHA of the "latest" release.

It turns out the Action we had been using for that "latest" check doesn't play nicely with the version naming we use. GitHub's "Releases" page seems guilty of the same, which you can see in my personal repo where I was testing out these fixes: The release ending in -10 appears lower down in the sort order than the one ending in -9. Since it's just a tag_name in GitHub's schema, I guess it's sorting as strings in a way that ignores their numeric significance.

I looked a little closer at the Action we'd been using and shopped for some alternatives, and indeed, they seem to be trying to be clever by downloading all the releases and then doing some kind of local sorting that still screws us. As it turns out, a straight hit on GitHub's /repos/{owner}/{repo}/releases actually does what we want, and thankfully I did find an action that uses it. Here's the proof from my personal test repo that shows the old Action doing the wrong thing and the new one doing what we want.

One caveat is that the new Action happens to use the set-output command that's set to be deprecated, so some warnings are surfaced when it runs. I do see there's an open Issue gregziegan/fetch-latest-release#14 to address this. In a pinch I also can see that writing our own curl & jq to repeat the essential logic would not be difficult, so if GitHub breaks us I could cook that up in in a pinch.