This should recompute or reconfigure the build based on new information about the assessment. One obvious use case is if a dev submits a patch that alters the drupalci.yml file to reconfigure the simpletest job to only run certain tests.
Drupalci testbot needs to split up behaviors into two categories:
Upstream from the testbot, any existing drupalci.yml file will be merged into the build.yml file specified to the testbot. We only need to change the behavior of the build process if the issue patches drupalci.yml, because only then will it be different from the assessment phase already present in build.yml.
If the issue does patch drupalci.yml, we then substitute the assessment phase from drupalci.yml for the one present in build.yml.
For consistency and sanity, we'll split this up:
#2950594: Add separate assessment-phase build
#2950939: Use the drupalci.yml to specify assessment if modified
Comments
Comment #2
mile23This spec is different enough from #2901677: Allow projects to contain their own drupalci.yml file that I'm going to close it in favor of this one.
Comment #3
mile23Comment #4
mile23Comment #5
mile23Comment #6
MixologicOne thing that came up in discussions is that a drupalci.yml could potentially contain assessment steps for multiple triggers beyond just patch testing. We, currently, are only going to pull in the assessment phase configuration for the issue testing if the patch modifies the build.yml. This may result in no changes if the patch only changes other triggers, but that should be okey dokey.
Comment #7
mile23Added child issue #2950939: Use the drupalci.yml to specify assessment if modified
Comment #8
MixologicAll the downstreams are passing tests and merged in.