@sgallagh noticed the EOL date in /etc/os-release in Fedora 41 is wrong (it's in May 2025, should be in November 2025).
We could add some kind of heuristic to catch this in the os_release.pm test. Perhaps we could do something like "when testing a compose whose release number is higher than current stable, the EOL date must be more than 8 months in the future", or something like that?
os_release.pm
That's probably the best heuristic we can do here. Ideally, we'd have a central place to query what the expected value is here, but the only place I can think of for that would be https://fedorapeople.org/groups/schedule/ and we also discovered THAT was incorrect in some places.
The above location provides a json file from which the value could be easily taken, but how do we make sure if this value is correct?
I have also checked the os-release file that offers the following variable (on F41 currently) SUPPORT_END=2025-12-15.
SUPPORT_END=2025-12-15
I am thinking about the condition and it should definitely be longer ahead. We will mostly test versions that are not stable yet (and they should be supported for a year approximately), which means that at the time of testing, the EOL should be longer than 12 months? Would that not be more exact?
Also, since the above value shows the exact date, we could perhaps only tolerate a time frame around the release time in a years time, such as Sept, Oct, Nov, and Dec for an autumn release, or something like that.
When we know exactly, what we want, I will make it happen.
Metadata Update from @lruzicka: - Issue assigned to lruzicka
Yeah, the reason I suggested a heuristic is that there are various potential sources of truth here that don't always agree with each other, so an exact date check is difficult. (Although I suppose we could try and use this test as a way to get them all lined up). There's at least the schedule page, whatever's in /etc/os-release , and whatever Bodhi says at https://bodhi.fedoraproject.org/releases/F41 , and there may be others I'm forgetting.
It also occurs to me that we know whether the release being tested is a development release or not, because we have the CURRREL variable.
So...hmmm. I'd say these checks are all candidates:
We can probably do 1+2, or 1+3. What do you all think?
I'd vote for 1+3, personally. It'll help ensure that the schedule, Bodhi AND os-release all agree AND it must be a reasonable time in the future.
Gotcha, @sgallagh. Let me try something out.
Metadata Update from @lruzicka: - Custom field story_points adjusted to 6
The os-release.pm now tests the EOL scenarios 1 and 3.
os-release.pm
https://pagure.io/fedora-qa/os-autoinst-distri-fedora/pull-request/350
Currently, both of the tests fail for F42, see https://bugzilla.redhat.com/show_bug.cgi?id=2329961
Also, there is no date set in Bodhi currently, so we end up with the beginning of Epoche (1970-01-01) and the os-release has an incorrect EOL 2025-05-13. Fedora Schedule has 2026-05-13. Which of the dates should become the source of truth?
Commit a9397e2 fixes this issue
Log in to comment on this ticket.