Include version.php check on CiBoT checks

[junpataleta]

We've recently encountered version.php check failures on issues that landed in integration. It might be worth looking into running version.php checks when the issue is sent to peer review or integration review in order to catch this type of failure earlier.

[stronk7]

Hi,

as commented in the chat, this is possible, but comes with some extra complications.

The main point is that the versions checker comes with different configuration per branch, where it's specified which versions (dates) or range of versions (dates) are allowed on each, for example:

• 401_STABLE: 20221128
• 402_STABLE: 20230424
• master (4.3.dev): 20230424-20231009

And that configuration is something that is setup as part of the release process, when new branches are created and configured.

So, if we want CiBoT to be able to perform those checks we need to make it aware of the configurations per branch, as commented above.

Again, it's not impossible, but maybe first we should "invent" a way to have the configuration in one place and then make all the different jobs to be able to use it... say:

1. Something like we do for some jobs, where we specify, per job, a long variable with values per branch, for example:

cf_branches = 'MOODLE_39_STABLE:customfield_15421,MOODLE_311_STABLE:customfield_15610,MOODLE_400_STABLE:customfield_15910,
MOODLE_401_STABLE:customfield_16212,MOODLE_402_STABLE:customfield_16510,master:customfield_10111'

(where we specify the name of the field in the Tracker for every branch, we have other variables similar, with php versions per branch and others, all them configured also as part of the release process)

2. Create a new place and format, richer, where we can specify an undetermined number of variables per branch, say:

MOODLE_401_STABLE:
    tracker_field: MOODLE_402_STABLE
    php_version: 8.0
    allowed_versions: 20230424
    ...

(so we only configure all the information in one place - maybe it can be a file under git, why not. And then, all the jobs needing that information just look to that unique source of information. Maybe allowing the information to be overridable if specified).

So, yes, this needs a little bit of thinking (which format to use, so it can be accessed from shell scripts, from php...) and preparations. Once we have it, modify the existing jobs to be able to read that information and, of course, modify the release process to ensure that the information is updated whenever a new branch is created and master bumped.

Ciao :-)