Manually merge 3.0.x into master #4352
Conversation
This must have been forgotten in a previous commit I made about this.
Using moving aliases has proven troublesome in the past.
Add Statement::fetchAllKeyValue() and ::iterateKeyValue()
Modernize existing ga
When we push to a branch on origin and make a PR, we see double the normal amount of jobs because of this.
I somehow missed another occurrence.
The end goal is to have a generic workflow that can be contributed back to our .github repository.
It is more concise.
Static analysis workflow
Add Statement::fetchAllIndexedAssociative() and ::iterateIndexedAssociative()
It should be faster, and will result in one fewer CI platform to maintain.
Minor CS improvement - use ::class for TestCase::expectException input
Migrate jobs away from Travis to Github Actions
Rename Comparator::diffTable() params - from/to instead of 1/2
Update Psalm to 3.17.2 and lock the version used with GitHub Actions
morozov
force-pushed
the
master
branch
3 times, most recently
from
aaa48b6
to
fab30b8
Compare
|
@greg0ire some jobs didn't start even after I reopened the PR. Not sure where "PHPUnit with IBM DB2 (8.0)" comes from. It's no in the build matrics and isn't expected to work yet. For the reference, #4351 also had 55 jobs but there wasn't "PHPUnit with IBM DB2 (8.0)" there. P.S.: I set all PHPUnit jobs except for "minimum-stability dev" to required in the branch settings. UPD: I disabled the missing checks as required similarly to how they are disabled for the older branches. But this doesn't look good. |
|
Hm… how do we get them off the list? In my experience, removing Travis is quite non-straightforward. On a personal project, I ended up removing all the webhooks, etc. manually. If somebody files a PR with the matrix changes, and they persist in our branch settings just because of that, it's quite disturbing. |
By waiting for one week I think 😅
|
No description provided.