Fetch stats for issues closed for version-data

[JordanMussi]

E.g. for MyBB 1.8.22:

resolved_issues_number: "36"
resolved_issues_age_median: "13.5"
resolved_issues_age_mean: "37.8"
resolved_issues_link: "https://github.com/mybb/mybb/issues?q=is%3Aissue%20is%3Aclosed%20label%3As%3Aresolved%20milestone%3A1.8.22"

[dvz]

To keep it simple and hosting-agnostic, how about resolving everything (API URLs, repository paths) from a single repository URL:

<property name="issuesRepository" value="${sourceGitRepository}" />

We can use e.g. parse_url() with a switch to match a service (with GitHub implemented) within

getIssuesData(string $issuesRepository, string $resolvedIssuesMilestone): array

Overriding milestones in build.properties may be easier with titles instead of numbers. If we rename the property resolvedIssuesMilestone for consistency (and don't fetch if empty) and define in build.xml with

<property name="resolvedIssuesMilestone" override="false" value="${targetVersion}" />

we can use it to create a pattern for resolved_issues_link (inserted if not empty; unrelated to fetching Issues data):

<property name="resolvedIssuesLink" value="https://github.com/mybb/mybb/issues?q=is%3Aissue%20is%3Aclosed%20label%3As%3Aresolved%20milestone%3A${resolvedIssuesMilestone}" />

[JordanMussi]

That would be better but might be unnecessary complication at this point because if we are't implementing a different hosting provider why be agnostic before we need to?

Overriding milestones in build.properties may be easier with titles instead of numbers. If we rename the property resolvedIssuesMilestone for consistency (and don't fetch if empty) and define in build.xml with

I went with the milestone number as you can fetch by the number, overriding the name still means fetching all milestones and looping through to find the right one.

I'll implement your other suggestions now :)

[dvz]

That would be better but might be unnecessary complication at this point because if we are't implementing a different hosting provider why be agnostic before we need to?

We should get cleaner code; the current system is not necessarily short-term, since we may reuse it to automate things later. I've updated PHP to 7.4 and when we get the chance we should update the PHP scripts to use type declarations and strict mode.

I went with the milestone number as you can fetch by the number, overriding the name still means fetching all milestones and looping through to find the right one.

Yes, in this case it would fetch the ID as an intermediate step in all cases - it doesn't look like there would be any benefit to people operating on IDs directly.

[JordanMussi]

Fair enough, I was going with how the code is already structured else I would've used a library for the API :-)

[JordanMussi]

Also I meant to mention this before but do you think it would be better to trigger the issue stats in a GitHub action rather than in the package build process? Removes the need to be online for the package build and the issue stats aren't exactly necessary at release and could be done when pushing to mybb/mybb.com. The graphs don't have to include the current release at the exact moment it is released.

I only worked on the code for this repo since it is where the release YAML is generated but I think it would be better to not be done on the critical flow.

[dvz]

Ideally these graphs would be provided by GH's Insights, or a third party service, as these are less related to release metadata and more to development metrics (and so that we don't have to deal with it at all), but I wasn't able to find anything useful.

We include the issue count in version files (which should be available to the release manager to generate announcements), but it may make sense to have some cache file updated in mybb/mybb.com/_data on mybb/mybb Issue events just for the graph (in which case the issue count can be grabbed manually to keep this system light). It would be easier to add more metrics without creating cached properties in version files, too.