- Assigned to wim leers
- π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
Actually, I think I already wrote everything that we need here β¦ I was forced to do so in π Limit trusted Composer plugins to a known list, allow user to add more Fixed .
See #3331168-13: Limit trusted Composer plugins to a known list, allow user to add more β through #3331168-17: Limit trusted Composer plugins to a known list, allow user to add more β and all commits + comments in between.
Verifying that nowβ¦
- Assigned to tedbow
- π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
I thought, but I was wrong!
The scope of this issue is to check
StatusCheckEvent
before starting the whole build process test (or at least as early as possible).In π Limit trusted Composer plugins to a known list, allow user to add more Fixed , I did improve build test coverage relating to validation and in principle also around
StatusCheckEvent
. But:- it aimed to improve the DX of build tests by not failing in obfuscated ways, by surfacing the actual error messages on the visited pages during the build test β during, not before/early
- it aimed to do so for all events, not just status check events
Opening a new issueβ¦
- Assigned to wim leers
- π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
Hah, just discussed with @tedbow, and he actually wants to expand the scope of this issue slightly because there is a lot of overlap in the code needed for the current scope and what I did over there ππ
Bringing over the relevant pieces from π Limit trusted Composer plugins to a known list, allow user to add more Fixed in a new MR.
- @wim-leers opened merge request.
- π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
The new branch was ~2 months behind because that's when the issue fork was created β¦ so first caught it up to current
8.x-2.x
. - π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
Brought over the 4 essential commits from π Limit trusted Composer plugins to a known list, allow user to add more Fixed . Tests pass locally π
But β¦
ModuleUpdateTest
fails locally. I was hoping to only have to modify that test in π Limit trusted Composer plugins to a known list, allow user to add more Fixed , but it looks like the improved error checking inBuild
tests show that this is actually pseudo-broken in HEAD β HEAD just happens to ignore the error message πLet's see if DrupalCI confirms that finding β¦
- π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
Looks like
ModuleUpdateTest
passes on10.0.x
. But I'm fairly certain it'll fail on9.5.x
. Queued test for that. See #3331168-17: [PP-1] Limit trusted Composer plugins to a known list, allow user to add more β for the analysis behind that statement. - Assigned to tedbow
- π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
Well β¦ okay β¦ I don't understand this, but for some reason it's passing. Okay. Yay for a smaller/simpler set of changes here then! π
As discussed, back to you, @tedbow, to extract part of what I did and run it automatically at the start of each build test! π
- Assigned to wim leers
- Status changed to Needs review
almost 2 years ago 5:36pm 27 January 2023 - πΊπΈUnited States tedbow Ithaca, NY, USA
Ok brought in my changes into 3320792-explicit-early .
1 test failed but I pushed up a fix for it
- πΊπΈUnited States tedbow Ithaca, NY, USA
Created π Assert no errors after creating the test project in ModuleUpdateTest Needs review as a follow up but that issue is tagged
contrib-only
so I am not adding thesprint
tag since we don't need to do it now. - πΊπΈUnited States tedbow Ithaca, NY, USA
I would really like to get this in and I don't think the functional test are going to share that much code so I rescoping this the orignal
We could use the same code in functional test like I did in the original MR https://git.drupalcode.org/issue/automatic_updates-3320792/-/blob/332079...
but I think that is overkill for the functional tests to rely on the UI when I think all we have to do in functional test is to use our existing function like
$this->assertStatusCheckResults([]);
We just have to figure where to call because some functional test are step up to specifically fail status checks and other don't enable automatic_updates until later so calling
$this->assertStatusCheckResults([]);
would only assert package_manager validatorsand we can't simply enable automatic updates ,
$this->assertStatusCheckResults([]);
and then disable it because some test what happens when we enable automatic_updates so doing this would change test coverage.TLDR I don't want to figure all that out right now and put off the fix for build tests.
Created follow-up π Assert status checks pass as early as possible in kernel and functional tests Closed: outdated
- Issue was unassigned.
- Status changed to RTBC
almost 2 years ago 10:40am 30 January 2023 - π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
Let's ship this! π’
This is definitely a net improvement, and all your changes make sense to me π
- Assigned to tedbow
- πΊπΈUnited States tedbow Ithaca, NY, USA
`composer phpcs` ran locally
merged 8.x-2.x , will commit when green
- 0316b695 committed on 8.x-2.x
Issue #3320792 by tedbow, Wim Leers, kunal.sachdev: Make build tests...
- 0316b695 committed on 8.x-2.x
- Status changed to Fixed
almost 2 years ago 1:19am 31 January 2023 Automatically closed - issue fixed for 2 weeks with no activity.