Problem/Motivation
The build process needs to be able to determine when to use the drupalci.yml file instead of the build.yml from upstream for the assessment phase.
Upstream (d.o, jenkins..) will merge the drupalci.yml from the repo into its own build.yml. Therefore we only want to merge drupalci.yml in the build process if it's been changed.
Currently we'll do this when the drupalci.yml file itself is changed by a patch. In the future we might figure out whether the changed build trigger within the drupalci.yml file matches the trigger for the current event.
Proposed resolution
After #2950594: Add separate assessment-phase build we'll have made the first steps at separating concerns for the assessment phase within the code. We can substitute the contents of drupalci.yml for this assessment phase in this issue.
That leaves figuring out when to perform this substitution, and for that we'll use a codebase-assemble phase plugin which determines if the drupalci.yml file is changed, and if it is, pull the named build from the YAML, and parse that into plugins which replace the assessment phase.
Comments
Comment #3
mile238f9da52 is WiP. It adds a message plugin so we can say things like, "This stage has been replaced." It also replaces the assessment stage with drupalci.yml.
Like this:
I'm acting as if there aren't build events yet, because there aren't. We can shoehorn that in without much hurt in another issue.
Also minor docblock cleanup type stuff so my brain and IDE are happy.
Comment #5
mile23Per slack conversation, reverted some CS type changes, also renamed ReloadAssessment to UpdateBuild. Still needs work, is WiP.
Comment #7
mile23Still todo: Make sure we're looking in the project root for drupalci.yml core, contrib. Add tests which pull patches for core, contrib.
Comment #8
mile23#2951843: Use drupalci.yml to fail test runs early holds patches used for testing here.
Comment #10
mile23Sure would be nice to know whether there's build.yml metadata telling me whether I should look in core/ or not... :-)
Comment #12
mile23Added #2952984: Add example drupalci.yml file to un-suppress deprecations to Examples for a patched drupalci.yml against contrib.
Comment #14
mile23OK, now it finds drupalci.yml in contrib.
Needs some look-see.
Comment #15
mile23Our most bestest use-case: #2947470: Update phpunit as part of build
Comment #16
MixologicIm in the midst of reviewing this.
Comment #17
MixologicAight, everything looks good from my perspective. Im a little bit concerned about the testing as it seems like we're adding things just to make it testable (i.e. we really should not be able to make this do anything if there is no patch), but Im fine with it as is. I've merged this into dev along with a couple other branches to that revealed other errors, so we're running the test suite on jenkins now.
I did some premature branch cleanup, but I did some dumb branching of branching so new fixes = new branches if dev tests do not pass.
Comment #18
mile23That's what we're testing. If you mean 'always-use-drupalci-yml' then yah, that's something we don't actually need, and is an artifact of wandering in the weeds.
Comment #19
Mixologicyeah, thats what I meant: 'always-use-drupalci-yml' didnt seem like a config we really needed. +1 to #2953938: Remove update_build's always-use-drupalci-yml config