Improve version update scraping; drop 5.7 on Debian (eol) and add 8.1 innovation on Oracle Linux

[tianon]

This gives us more accurate version scraping that's not reliant on the cache of the HTML file listing (which instead matches how yum/dnf query these version numbers, so should stay in sync better).

This should fix our issues with CI sometimes returning a mismatch in 8.0 versions.

However, this causes a mismatch in 5.7 versions because the latest 5.7 release (that we were not picking up before due to the aforementioned HTML caching but are now with this updated code) is apparently not built/released for Debian (https://dev.mysql.com/downloads/mysql/), so we also need to decide whether we're going to introduce Debian/Oracle version skew or perhaps deprecate/remove the Debian variants of 5.7 (which is ostensibly EOL in ~3 months).

See also https://blogs.oracle.com/mysql/post/introducing-mysql-innovation-and-longterm-support-lts-versions (however, I cannot seem to find an APT or Yum repo that contains the new 8.1 packages 🙈).

[yosifkit]

we also need to decide whether we're going to introduce Debian/Oracle version skew or perhaps deprecate/remove the Debian variants of 5.7 (which is ostensibly EOL in ~3 months).

If we allow the versions to skew, then it might imply that 5.7.42 on Debian is still upstream supported when that is no longer the case (i.e. it won't have any MySQL bugfixes however unlikely they may be for the 5.7 Oracle Linux packages).

On the other hand, it doesn't take effort to just leave the file for the three months. Dropping it early doesn't really change users' behavior; they'll still be pulling and using an outdated image anyway so might as well give them a slightly more up to date image for a few months.

[qeepcologne]

in the end 8.1 packages offered via update are downloaded from:
http://repo.mysql.com/apt/ubuntu/pool/mysql-innovation/m/mysql-community/

[tianon]

Nice find, @qeepcologne! 🙇

On the other hand, it doesn't take effort to just leave the file for the three months. Dropping it early doesn't really change users' behavior; they'll still be pulling and using an outdated image anyway so might as well give them a slightly more up to date image for a few months.

My concern with doing so is that users will be receiving "fresh" images that give them some indicator that the thing is still active, maintained, and supported, and that just isn't true, so my own preference would be to drop it such that they can see staleness signals.

[yosifkit]

Seems reasonable to me 👍

$ diff -u ../official-images/library/mysql <(./generate-stackbrew-library.sh)
...
-Tags: 8.0.34, 8.0, 8, latest, 8.0.34-oracle, 8.0-oracle, 8-oracle, oracle
+Tags: 8.1.0, 8.1, 8, innovation, latest, 8.1.0-oracle, 8.1-oracle, 8-oracle, innovation-oracle, oracle
+Architectures: amd64, arm64v8
+GitCommit: eb1850601849ef7ef77a23f017a20debc95d597c
+Directory: innovation
+File: Dockerfile.oracle
+
+Tags: 8.0.34, 8.0, 8.0.34-oracle, 8.0-oracle
 Architectures: amd64, arm64v8
 GitCommit: f4030aebf6a63d640f7085fb3e4601b4e70313c8
 Directory: 8.0
 File: Dockerfile.oracle

-Tags: 8.0.34-debian, 8.0-debian, 8-debian, debian
+Tags: 8.0.34-debian, 8.0-debian
 Architectures: amd64
 GitCommit: f4030aebf6a63d640f7085fb3e4601b4e70313c8
 Directory: 8.0
 File: Dockerfile.debian

-Tags: 5.7.42, 5.7, 5, 5.7.42-oracle, 5.7-oracle, 5-oracle
+Tags: 5.7.43, 5.7, 5, 5.7.43-oracle, 5.7-oracle, 5-oracle
 Architectures: amd64
-GitCommit: 2baf92d30620d7d123141b98988b0d42d2156351
+GitCommit: c13cda9c2c9d836af9b3331e8681f8cc8e0a7803
 Directory: 5.7
 File: Dockerfile.oracle
-
-Tags: 5.7.42-debian, 5.7-debian, 5-debian
-Architectures: amd64
-GitCommit: 611aa464a96f69e5d4d4172b14ca829ded162b42
-Directory: 5.7
-File: Dockerfile.debian