ENH Update reference to supported modules data #45

GuySartorelli · 2024-05-08T03:32:52Z

Issues

Update repositories that pull in data from silverstripe/supported-modules .github#237

GuySartorelli · 2024-05-08T04:32:20Z

funcs_scripts.php

+    if (isset($repoData['type'])) {
+        return $repoData['type'] === 'recipe';
+    }


The type key is only available for repos in the "supportedModules" category - but e.g. testing-recipe is a recipe so we need to still check the old way as well.

Same idea with all other changes below checking type.

Why do we even need to use the supported-modules repositories.json as the source of truth instead of composer.json of each module? Nothing was broken before?

Ditto for all the other updates in the PR doing the same e.g. is_module()

Just feels more correct. I'll remove it if you insist, but I don't see any reason to.

I'd say remove it, it's confusing as to why we'd need two methods.

Having it here and then having a fallback of composer.json looks just like we don't trust supported-modules to be correct

looks just like we don't trust supported-modules to be correct

A comment could easily solve that lol. I'll remove it just to avoid ping pong, I think either way the result ends up being the same so it doesn't matter.

GuySartorelli · 2024-05-08T04:33:01Z

funcs_scripts.php

-    global $MODULE_DIR;
-    return !is_module() && strpos($MODULE_DIR, '/gha-') !== false;
+    global $GITHUB_REF;
+    return in_array(
+        $GITHUB_REF,
+        array_column(
+            MetaData::getAllRepositoryMetaData()[MetaData::CATEGORY_WORKFLOW],
+            'github'
+        )
+    );


All gha-* repos are in the workflow category, and nothing else is.

Should revert this, this one is like is_module() where we're not using MetaData as source of truth. This function is specifically for gha repos, and the naming convention on gha- will always be there, though there is some chance someone will put in a non-gha workflow file in the workflow section of repositories.json.

The reason we're not using MetaData in is_module() is because there might be repositories in other categories which are also modules, so we need to fall back on composer.json values.

This function is different. There's no need to fall back on anything, everything we need to know is in the CATEGORY_WORKFLOW category. All of the repositories in that category are the "gha-*" repositories. Nothing else is in that category. This is robust, and is much better than checking against a naming convention.

there is some chance someone will put in a non-gha workflow file in the workflow section of repositories.json.

If they do that, they're doing the wrong thing.
The same can be said of naming conventions - there is a chance someone could make a workflow repository that doesn't follow the naming convention, or could make another repository that accidentally starts with "gha-".

Both of those are a low chance and aren't worth considering IMO.

For context, the whole reason that category even exists in the file is so you can tell if something's a gha repo by just checking if it's in that category.

GuySartorelli · 2024-05-08T04:33:25Z

funcs_scripts.php

-    $s = read_file('.git/config');
-    if (!preg_match('#github.com:([^/]+)/#', $s, $matches)) {
-        error('Could not determine github account');
-    }
-    return $matches[1];
+    global $GITHUB_REF;
+    return explode('/', $GITHUB_REF)[0];


No need to check .git - we have this information ahead of time.

GuySartorelli · 2024-05-08T04:34:43Z

funcs_utils.php

-function extra_repositories()
-{
-    $importantRepos = [
-        'silverstripe/markdown-php-codesniffer',
-        'silverstripe/silverstripe-standards',
-        'silverstripe/documentation-lint',
-        'silverstripe/.github',
-    ];


The set of "extra" repos we're gonna end up with after this change is a lot bigger than we were getting before. I've added a note to silverstripe/.github#242 that when this gets run next we should take care to check if there's anything we want to skip and add an exclude list if there is.

GuySartorelli · 2024-05-08T04:35:21Z

funcs_utils.php

-    // Some repositories don't have a valid matching CMS major
-    $ignoreCMSMajor = [
-        '/silverstripe-simple',
-        '/markdown-php-codesniffer',
-    ];
-    foreach ($ignoreCMSMajor as $ignore) {
-        if (strpos($MODULE_DIR, $ignore) !== false) {
-            return CURRENT_CMS_MAJOR;
-        }
+    // This repo matches every major and matches start at the lowest - but we only want the highest stable.
+    if ($GITHUB_REF === 'silverstripe/silverstripe-simple') {
+        return MetaData::HIGHEST_STABLE_CMS_MAJOR;
    }


markdown-php-codesniffer will get correctly identified - but the theme still needs some help.

funcs_utils.php

emteknetnz · 2024-05-08T22:02:37Z

funcs_scripts.php

+    if (isset($repoData['type'])) {
+        return $repoData['type'] === 'recipe';
+    }


Why do we even need to use the supported-modules repositories.json as the source of truth instead of composer.json of each module? Nothing was broken before?

Ditto for all the other updates in the PR doing the same e.g. is_module()

funcs_scripts.php

emteknetnz · 2024-05-09T02:59:57Z

funcs_scripts.php

+    if (isset($repoData['type'])) {
+        return $repoData['type'] === 'recipe';
+    }


I'd say remove it, it's confusing as to why we'd need two methods.

Having it here and then having a fallback of composer.json looks just like we don't trust supported-modules to be correct

emteknetnz · 2024-05-09T21:26:59Z

funcs_scripts.php

-    global $MODULE_DIR;
-    return !is_module() && strpos($MODULE_DIR, '/gha-') !== false;
+    global $GITHUB_REF;
+    return in_array(
+        $GITHUB_REF,
+        array_column(
+            MetaData::getAllRepositoryMetaData()[MetaData::CATEGORY_WORKFLOW],
+            'github'
+        )
+    );


Should revert this, this one is like is_module() where we're not using MetaData as source of truth. This function is specifically for gha repos, and the naming convention on gha- will always be there, though there is some chance someone will put in a non-gha workflow file in the workflow section of repositories.json.

This was referenced May 8, 2024

ENH Add functionality required by other repositories silverstripe/supported-modules#29

Merged

Update repositories that pull in data from silverstripe/supported-modules silverstripe/.github#237

Closed

GuySartorelli force-pushed the pulls/main/new-supported-modules branch 4 times, most recently from de66d65 to 91210a7 Compare May 8, 2024 04:31

GuySartorelli commented May 8, 2024

View reviewed changes

GuySartorelli force-pushed the pulls/main/new-supported-modules branch from 91210a7 to f7d6f2d Compare May 8, 2024 04:37

emteknetnz requested changes May 8, 2024

View reviewed changes

emteknetnz mentioned this pull request May 8, 2024

Repository owner is incorrectly identified for the simple theme #44

Closed

GuySartorelli force-pushed the pulls/main/new-supported-modules branch 2 times, most recently from f4c0803 to 8123501 Compare May 9, 2024 00:18

emteknetnz requested changes May 9, 2024

View reviewed changes

ENH Update reference to supported modules data

d80e9f7

GuySartorelli force-pushed the pulls/main/new-supported-modules branch from 8123501 to d80e9f7 Compare May 9, 2024 04:17

emteknetnz requested changes May 9, 2024

View reviewed changes

emteknetnz approved these changes May 9, 2024

View reviewed changes

emteknetnz merged commit c42e9b4 into silverstripe:main May 9, 2024
1 check passed

emteknetnz deleted the pulls/main/new-supported-modules branch May 9, 2024 23:13

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ENH Update reference to supported modules data #45

ENH Update reference to supported modules data #45

GuySartorelli commented May 8, 2024 •

edited

Loading

GuySartorelli May 8, 2024

emteknetnz May 8, 2024

GuySartorelli May 9, 2024

emteknetnz May 9, 2024

GuySartorelli May 9, 2024

GuySartorelli May 9, 2024

GuySartorelli May 8, 2024

emteknetnz May 9, 2024

GuySartorelli May 9, 2024

GuySartorelli May 9, 2024

GuySartorelli May 8, 2024

GuySartorelli May 8, 2024

GuySartorelli May 8, 2024

emteknetnz May 8, 2024

emteknetnz May 9, 2024

emteknetnz May 9, 2024

ENH Update reference to supported modules data #45

ENH Update reference to supported modules data #45

Conversation

GuySartorelli commented May 8, 2024 • edited Loading

Issues

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

GuySartorelli commented May 8, 2024 •

edited

Loading