Eventually, d.o upstream will allow for different types of build triggers, which result in different build targets for the testbot.
This will mostly be transparent to the testbot, because the d.o layer will generate a full spec as a build.yml file.
However it also means that patched drupalci.yml files which need to be parsed at runtime could also specify build targets. We load drupalci.yml files if they're patched, and we'll need to know which target to execute.
This issue is mostly a placeholder for figuring out what this means.
Comments
Comment #2
mile23Comment #3
mile23Comment #4
MixologicCurrent upstream target is the same for every test, which we're calling the
developmenttarget.The next target to come down the line will likely be
regression. The main difference is that we'd skip some steps in regression testing (like phpcs/stylelint/phplint etc) because they've already been run as part of the development phase.For now, a drupalci.yml would have the main root
buildkey.When we add additional ones, we'll add them as
build.regression, and always assume thatbuild, all by itself, meansbuild.developmentThe other assumption that we'll make, for now, is that even if a developer patches the
build.regressionsection of their drupalci.yml, we're still only going to replace thebuild.developmentsection for that particular patch test.They'll have to manually run a regression test after they commit to see if the patch to their drupalci.yml build.regression section was effective. (We could probably, in the future, offer an ad-hoc testing button to run the other targets in the issue)
Comment #5
MixologicSo, when pift creates a build, should it set a variable somewhere in the build.yml that is the 'build target' ? or should it send the build target as a label to begin with?
i.e
build.developmentat the top level?Comment #6
mile23If #2976407-64: Use drupalci.yml for composer dependency min/max testing - DO NOT COMMIT is critical and essentially a dupe/closed in favor of this issue, then this issue should be critical as well.