On Tue, Oct 18, 2022 at 03:10:07PM +0500, Илья Шипицин wrote: > > Sorry I didn't see the first commit that introduced this behavior. I'm > > not sure we would want to replace the version automatically in the CI > > for OpenSSL. > > > > it was supposed behaviour for OPENSSL_VERSION=latest >
Yes, that's exactly why I said that I missed the introduction of that change :-) > > Currently we are testing the stock OpenSSL of the ubuntu which is 1.1.1, > > the 1.0.2u and the "latest". The latest is currently a 3.0.x but once > > the 3.1.x is released we would still need the 3.0 branch. > > > > I think we should review our approach to "stock" and "latest" when > ubuntu-latest > will be 22.04 (it is shipped with 3.0.X) > > I'll have a look at your point as well Sure, that's not urgent, we will need to add a 1.1.1 separately in this case. > > I think we need something to test the latest release of a branch, and > > not the latest version of all branches. Maybe we could specify "3.0.x" > > to get the latest 3.0? > > > > maybe-maybe-maybe. > > we can introduce "latest in 3.0.x" I guess. not much to code. I think that's the most logical behavior we need for testing HAProxy without breaking the CI because of a major change in the library. What we need is to test our code for each of our commit, if the CI break on our commit because we changed the lib version it's difficult to know where the issue is. Maybe we could have a separated CI job with the "latest" version, so we ensure that this is running correctly before integrating the version to the "per-commit" CI jobs. What do you think about that? It seems like a good compromise to me. -- William Lallemand
