Re: [docs] [PATCH v2 1/3] tools/fetch-releases-json: add to fetch and format releases.json

["Antonin Godard" <antonin.godard@bootlin.com>]

Hi,

On Tue Mar 3, 2026 at 3:48 PM CET, Quentin Schulz wrote:
> Hi Antonin,
>
> On 3/3/26 2:14 PM, Antonin Godard wrote:
>> Hi,
>> 
>> On Fri Feb 27, 2026 at 11:26 AM CET, Quentin Schulz via lists.yoctoproject.org wrote:
>>> Hi Antonin,
>>>
>>> On 2/26/26 3:00 PM, Antonin Godard via lists.yoctoproject.org wrote:
>>>> Add a simple script that can be used to fetch and format the
>>>> releases.json file from https://dashboard.yoctoproject.org/releases.json.
>>>>
>>>
>>> OK but why do we want this in the tree? It'll still be regularly outdated.
>>>
>>> I understand not wanting to rely on a network connection, but we already
>>> need that for the bitbake's object.inv we download... so this ain't that
>>> much different.
>> 
>> You're right, I forgot about that inventory file :( made this change with an
>> offline build in mind.
>> 
>> Fetching the file when building seems like a proper solution, although:
>> 
>> - IMO, we need to fallback on fixed values, even if they're outdated, to not
>>    block a documentation build if we can't fetch the releases.json file
>> 
>
> Makes sense. I actually thought about this a few days ago and I was 
> wondering if we shouldn't simply have a single version as fallback... 
> The current one. There's no reason to show multiple versions in the 
> switcher (and elsewhere?) when there's only one built locally?
>
> So maybe still generate the file from git and not even attempt to 
> download releases.json?

Actually, we can simply have some default values for the following variables:

activereleases = ["whinlatter", "scarthgap", "kirkstone"]
devbranch = "wrynose"
ltsseries = ["wrynose", "scarthgap", "kirkstone"]
release_series = collections.OrderedDict({
    "wrynose": "6.0",
    "whinlatter": "5.3",
    "scarthgap": "5.0",
    "kirkstone": "4.0",
})

And fallback on them when we don't find a releases.json file locally and we
aren't able to fetch it remotely. This should happen rarely, but I've added a
warning if that happens (working on it right now).

I'd rather keep the switchers version as it is, even in this case where we build
locally and we only have one version to display. Just so it sort of matches what
we're supposed to get from a releases.json file. I believe there are
implications in how we compute the values in poky.yaml.in, which rely on this,
so I'd rather not over-complicate it and provide default values in case we can't
find a releases.json file, which should happen rarely anyway.

>> - on the Autobuilder, we need to do the opposite: block a build if we can't
>>    fetch the releases.json file
>> 
>> - avoid fetching the file again if we already did (especially important on the
>>    Autobuilder as we don't want the file to be fetched for every tag + we don't
>>    want it to change during a build)
>> 
>
> Wondering if we can't simply handle releases.json downloading 
> externally. I think we should still have whatever handles releases.json 
> in the git repo(s) (but maybe not?) but we can simply put releases.json 
> somewhere the script in the repo expects one to be present.
>
> Essentially... if there's a releases.json available at location X, you 
> use it, if not, then you use the fallback of the current version. The 
> git repo wouldn't have a releases.json, only the autobuilder downloads 
> it once before building all docs.

> I guess the main issue is that we wouldn't know whether the current 
> version is EoL if you don't download releases.json? Is it important? 
> (thinking about people building the docs locally such that their 
> colleagues only look at the documentation for the version they actually 
> use).

Not sure I follow exactly, but I'm working on the Autobuilder part too which
generates this releases.json on the fly and uses it for each docs build. I hope
that will answer most of your questions here.

I think we still want to fetch the releases.json file in yocto-docs though, to
give the user building locally an accurate version of what is hosted on
docs.yoctoproject.org (and it doesn't cost much). And anyway, as you reminded,
if a user cannot fetch the releases.json file from the remote location, they'll
fallback on some possibly outdated active releases array (the default values
above), but they'll also have a wall of errors due to lack of bitbake inventory.

Antonin