podman: add livecheck

[timsutton]

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

podman can push a tag for some time before the official release.

This livecheck aims to capture the version from the href that will link out to GH releases, like this:

My first time doing any livecheck additions, LMK if there's anything unusual I'm doing here!

[samford]

If the issue is only that there can be a notable span of time between when a version is tagged and when the corresponding GitHub release is created, we can simply use the GithubLatest strategy. I've added suggestions to bring this in line with similar checks.

Upstream created a 5.3.2 release less than an hour ago (~18 hours after the tag) but the homepage is still referring to 5.3.1. If we specifically need to match the version from the homepage instead of using the latest GitHub release, then I can add a different suggestion to bring the regex up to standard.

[samford]

Suggested change

	# checks the homepage since upstream can tag a new release for some time before
	# it is promoted to a new GitHub release and the homepage updated
	# There can be a notable gap between when a version is tagged and a
	# corresponding release is created and upstream uses GitHub releases to
	# indicate when a version is released, so we check the "latest" release
	# instead of the Git tags.

[samford]

Suggested change

	url :homepage
	regex(%r{Latest stable Podman.*containers/podman/releases.*?>(\d+(?:\.\d+)+)?</a}i)
	url :stable
	strategy :github_latest

[timsutton]

If we specifically need to match the version from the homepage instead of using the latest GitHub release, then I can add a different suggestion to bring the regex up to standard.

Thanks for the review! My main motivation was to have livecheck consider the new version only based on what's on the website. It looks from containers/podman.io#364 like the website will similarly be not far behind a GH release, but that it's not totally automated.

I see autobump PRs (for various formulae) where folks will hold off and consider it a prerelease if the website hasn't yet updated.. and then need to check back on it later.

If we still want to consider the website as the best source of truth, I figured that this might be preferable over using the GithubLatest. And also that this question usually inovlves a tradeoff of "GH releases will be more stable to check than a webpage, but can lag behind the webpage content." What do you think is preferable in this case?

[SMillerDev]

I see autobump PRs (for various formulae) where folks will hold off and consider it a prerelease if the website hasn't yet updated.. and then need to check back on it later.

Yeah, we really need to make a decision what to do there. It was my understanding that we stopped doing GH latest because of rate limits. That's why I thought we should start using websites instead.

[timsutton]

Yeah, we really need to make a decision what to do there. It was my understanding that we stopped doing GH latest because of rate limits. That's why I thought we should start using websites instead.

That's partly where I came from as well.. our docs suggest to not use them unless we really need to, and it looks to me like in the case of podman, the website livecheck is feasible.

[ashley-cui]

FWIW the Podman team considers the upstream GH release as the official "release" time, regardless of when the tag is pushed or the website is updated. Although we do guarantee the website will be updated after the upstream release.

[samford]

FWIW the Podman team considers the upstream GH release as the official "release" time, regardless of when the tag is pushed or the website is updated. Although we do guarantee the website will be updated after the upstream release.

Thanks! I was going to open an upstream issue to ask for clarification of the release process, so you've saved me the trouble.

---

Short version: It sounds like GithubLatest is the way to go here. I updated my suggestions to clarify the situation in the comment.

Long version:

our docs suggest to not use them unless we really need to, and it looks to me like in the case of podman, the website livecheck is feasible.

We only use GithubLatest when necessary but we have a handful of formulae using a tag (or tag tarball) where we use it to address this particular issue (a gap between tag and release), so this is one of the appropriate use cases (I had it in mind while writing the docs). We just make sure to include a preceding comment to explain why it's necessary (often a variation of the suggested comment), as that allows us to quickly understand the context when making changes in the future.

Checking the upstream website is another way to address this situation and it can make sense if the website is kept up to date and they link to GitHub (ideally a specific release). If GithubLatest works, we usually only opt for the upstream website if they make it clear that a version isn't released until the website is updated or if GithubReleases is necessary and the website provides the same version information using a lighter check. I try to avoid using GithubLatest when possible (especially GithubReleases) but not in this scenario and not if the alternative may be less reliable (or require more maintenance over time).

The reason why I suggested GithubLatest here is because it may be more reliable than the regex that's required to check the homepage. The homepage HTML only provides the Podman CLI version in the inner text of the a element that you mentioned (i.e., the download links are programmatically produced from a JavaScript file with a hash filename) and the necessary regex is more fragile than I would like. Small HTML changes can cause it to break if we make it too explicit but it may match an inappropriate/unrelated version if we make it too loose. We're always doing a balancing act with regexes but I try to avoid matching loose text when possible, as it can be less reliable (i.e., most of our PageMatch checks are matching versions from URLs, filenames, etc. and that's usually less of an issue). [It may be a different story if the homepage linked to the versioned release (e.g., https://github.com/containers/podman/releases/tag/v5.3.2), as we could easily match it with something like %r{href=.*?/podman/releases/(?:tag/)?v?(\d+(?:\.\d+)+)["' >]/i.]

I see autobump PRs (for various formulae) where folks will hold off and consider it a prerelease if the website hasn't yet updated.. and then need to check back on it later.

When maintainers leave a comment like "Not the latest release yet" for a formula that's using a GitHub tag or tag tarball and the repository uses GitHub releases, that's often because livecheck is surfacing a new version from a Git tag but the GitHub release hasn't been created yet. Even though the formula only uses a tag or tag tarball, we wait for the release because some upstream projects feel comfortable retagging a version before the release is created and we would end up with a checksum mismatch.

In a perfect world, we would have livecheck check GitHub releases for all projects that use them but that could lead to rate limit issues and break CI (the token is used for more than livecheck) or lead to issues when running lots of checks locally (e.g., brew livecheck --tap ...). Some projects also create releases for other sub-projects (where "latest" may sometimes be for different software), so we would have to check multiple releases for some projects and we really try to avoid GithubReleases because those responses are fairly heavy.

---

Yeah, we really need to make a decision what to do there. It was my understanding that we stopped doing GH latest because of rate limits. That's why I thought we should start using websites instead.

We've gone through a few different phases over the years but we've been pretty consistent about only using GithubLatest when it's necessary/appropriate since ~2020. There was a brief period of time in 2020 where some livecheck blocks were added that checked GitHub releases even though it wasn't necessary but we reassessed and decided to limit that approach. Back then we were dealing with rate limit issues on homebrew-livecheck CI even for github.com release pages, so we only used that approach when Git wasn't sufficient.

Eventually we introduced the GithubLatest strategy to replace related livecheck blocks (using the same logic) and we updated those to use strategy :github_latest. We still have a small number of old livecheck blocks using GithubLatest when it isn't necessary and someday I'll find/remove those (and document the ones that are necessary) but there are other things higher up my to-do list right now.

I haven't seen rate limit issues when checking github.com release pages for years but now GithubLatest/GithubReleases check the GitHub API (which has an explicit rate limit), so we've continued to minimize use of those strategies. It's something we can reassess (e.g., we may want to use GithubLatest/GithubReleases for all formulae/casks using a GitHub release asset) but it may not be worth the overhead for packages that aren't autobumped (where we want greater reliability from livecheck). It's something we would need to address if we ever want to make autobump opt-out (rather than opt-in) but it would take some work (some projects are more consistent about releases than others).

[SMillerDev]

We've gone through a few different phases over the years but we've been pretty consistent about only using GithubLatest when it's necessary/appropriate since ~2020.

From what I see in core most maintainers just check the releases manually because they're worried about using the latest livecheck with the way the documentation is written.

If we can add more of them, I think the documentation should reflect that. If we can't, we should find a way to work around that.