Add ci.yml workflow to modules

emteknetnz commented 2 years ago

ACs

[x] Add workflow to all supported silverstripe modules to use ci.yml - NOTE: this needs to target the oldest supported branches and be merged-up, not just the default branches
[x] Best effort to maintain any custom logic within .travis.yml files
[x] Maintain travis ci support for a while to validate things work as expected
[x] Update all module readme status badges from travis-ci to github actions default branch
[x] Ensure workflows do not run on forks, or at least scheduled workflows do not run on forks
[ ] Workflows are green

ACs Round 2 PRs

[ ] Remove .travis.yml files
[ ] In ci.yml and keepalive.yml (and readmes gha-ci, gha-keepalive and gha-update-js) change startsWith(github.repository, '<account>/') to github.repository_owner == '<account>'
[ ] Some travis badges were not updated e.g. silvestripe/silversripe-postgresql - the initial $find in module-standardiser was too strict
[ ] Remove travis badges and add new CI badges to https://github.com/silverstripe/supported-modules
- [ ] Use the updated table to populate the supported modules table in silverstripe.org

Notes

Usually makes more sense to just hardcode things in ci.yml rather than trying to make ci.yml move configurable
Workarounds to make workflows not run on forks - https://github.com/microsoft/TypeScript/pull/48693/files - https://github.community/t/do-not-run-cron-workflows-in-forks/17636
When creating a pull-request to add ci.yml to a repo, it will run on pull-request BUT ONLY if there are free github action worker available. It will not queue the workflow like you would expect. This is certainly inconvenient.
I have validated that account that have maxed out their github actions workers will still queue up ci runs, provided there is a ci.yml defined on the repo - i.e. you cannot bypass ci.yml by just spamming pull-requests. Test here.

Custom .travis files

[x] ~~assets - PHP_COVERAGE_SUITE=assets .. to stop travis timing out after 10 minutes~~ not required
[x] graphql (both 3 & 4)
[x] framework - custom matrix cos phpcoverage was giving weird results on travis
[x] auditor - mfa + session_manager custom

Custom .travis files, though probably does not need to be custom

[x] recipe-core - requires themes simple + admin + versioned - but there's no behat
[x] vendor-plugin - may work out of the box with ci.yml
[x] sharedraftcontent
[x] userforms
[x] spellcheck - apt packages (ci.yml has this hardcoded)

Graphql3

[x] Graphql4 will install by default
[x] Add explicitly add a graphql3 behat 'extra_job' for asset-admin, versioned-admin and elemental

missing .travis.yml / ancient non-shared .travis

[x] mink-facebook-web-driver (only unit testing thing in vendor folder, should probably just remove)
[x] recipe-plugin (no current CI, no unit tests)
[x] recipe-testing (no current CI, no unit tests, no code)
[x] serve (has unit tests)
[x] testsession (no current CI, no unit tests)

.travis files where REQUIRE_EXTRA should be moved to composer.json require-dev

Note: keep silverstripe/frameworktest as a requirement in module ci.yml, rather than composer require-dev, because it should eventually get split to move the 'behat test models' to a separate module - issue. If/when that happens, consider moving the requirement of the new module to require-dev

[x] elemental-bannerblock require elemental
[x] recipe-form-building - requies gridfieldqueuedexport + queuedjobs
[x] blog - requires widgets, comments, content-widgets
[x] comments - requires ezyang/htmlpurifier
[x] contentreview - requires symbiote/silverstripe-queuedjobs
[x] externallinks - requires symbiote/silverstripe-queuedjobs
[x] fulltextsearch - requires queuedjobs and subsites
[x] recipe-blog - requires gridfieldqueuedexport, queuedjobs
[x] reciple-ccl - requires versioned
[x] recipe-solr-search - requires cwp/cwp, cwp/cwp-core, cwp starter theme
[x] securityreport - requires subsites
[x] sitewidgecontent-report - requies subsites, taxonomy, contentreview
[x] totp-authenticator - requires webautn-authenticator - other things are sorted in ci.yml

PRs - CI

PRs - Modules

emteknetnz commented 2 years ago

We'll use this to create all the initial pull-requests - https://github.com/emteknetnz/module-standardiser

It creates PRs that look like this https://github.com/silverstripe/silverstripe-tagfield/pull/212

All the cron jobs are scheduled at varying times throughout the week so we don't clog things up

For any custom logic, we'll add this manually after the initial pull-requests have been created

GuySartorelli commented 2 years ago

Looks like a lot of supported modules are missing from the PR list:

bringyourownideas/silverstripe-maintenance
bringyourownideas/silverstripe-composer-update-checker
bringyourownideas/silverstripe-composer-security-checker
colymba/gridfield-bulk-editing-tools
cwp/cwp-core
dnadesign/silverstripe-elemental-subsites
dnadesign/silverstripe-elemental-userforms
hafriedlander/phockito
hafriedlander/silverstripe-phockito
lekoala/silverstripe-debugbar
silverstripe/silverstripe-activedirectory
silverstripe/elemental-bannerblock
silverstripe/elemental-fileblock
silverstripe/environmentcheck
silverstripe/externallinks
silverstripe/fulltextsearch
silverstripe/gridfieldqueuedexport
silverstripe/html5
silverstripe/hybridsessions

Probably more too - I stopped checking when I got that far.

maxime-rainville commented 2 years ago

Didn't quite manage to get all the builds green, but these are mostly failures that just got highlighted by the new build system. We'll create a follow up card.

maxime-rainville commented 2 years ago

Didn't quite manage to get all the builds green, but these are mostly failures that just got highlighted by the new build system. We'll create a follow up card.

silverstripe / gha-ci