Active
Project:
DrupalCI: Drupal.org Testing Infrastructure
Component:
Policy
Priority:
Normal
Category:
Plan
Assigned:
Unassigned
Reporter:
Created:
1 Mar 2018 at 20:09 UTC
Updated:
24 Mar 2018 at 02:42 UTC
Jump to comment: Most recent
To enable build.yml processing in drupalci we'll need to do the following things:
Dispatcher.drupalci.org changes
Alter jenkins jobs to accept build.yml files and pass them to the testrunner
#2949247: dispatcher jenkins jobs should accept build.yml files
Changes to drupal.org:
Send build.yml file to jenkins as part of the job requesting.
#2909467: Start sending build.yml
Add a module that checks out the repo etc that things can use
Can be used for grabbing .environments/docker-compose.yml stuff too
drupalorg_repository_inspector(?)
#2949200: Add drupalorg_versioncontrol_repo_changes hook
Parse and store drupalci.yml as part of versioncontrol_arrival.
#2949212: Store drupalci.yml from repository branches somewhere
When triggering a test, Create a build.yml file by merging (overwriting) the keys in the default build.yml with the ones provided by the drupalci.yml in the repo
#2949214: Merge drupalci.yml with default build.yml to send to drupalci.
Drupalci Testbot Changes
Alter drupalci to expect the build.yml to come from jenkins instead of env vars
#2949248: Alter drupalci to expect the build.yml to come from jenkins instead of env vars
Add a plugin to drupalci that can re-configure the build if a patch changes the drupalci.yml file
#2949249: Allow a modified drupalci.yml file to change the testbot build
Add a pre and post assessment plugin so that devs can run things.
#2949251: Add a container_command and host_command Assessment plugin
Make the api more consistent:
#2953923: Convert configuration elements to be all hypens, ensure all plugin definitions use underscores
Create a default drupalci.yml that people can put into their projects
#2949253: Create a default drupalci.yml with build targets
Documentation Needed
Add documentation for drupalci.yml and howto accomplish certain things
#2949257: Document how to use drupalci.yml in a project
This phase will allow us to close/fix the following issues:
#2769599: [PP-1] Allow themes to be testable
#2853814: Composer require failure: Devel vs. Devel Node Access
#2937399: Support for downloading libraries
#2874411: "Javascript coding standards error" should not stop whole tests
#2947470: Update phpunit as part of build
Which may not seem like much, but theres a whole slew of other valuable things we'll be able to do once this is implemented. Like not running coding standards checks on rtbc retesting or commit regression tests, etc.
Comments
Comment #2
MixologicComment #3
mile23Nice. :-)
Comment #4
MixologicSo we've got some nice momentum here.
Drupal.org is now creating and sending a build.yml file to drupalci, which is really close to being able to allow for patches to affect the build.
Next up on the list is #2949200: Add drupalorg_versioncontrol_repo_changes hook, then #2949212: Store drupalci.yml from repository branches somewhere, then #2949214: Merge drupalci.yml with default build.yml to send to drupalci.
Comment #5
markhalliwellw00h00!
Comment #6
mile23Added #2951843: Use drupalci.yml to fail test runs early so there's a place to hold patched drupalci.yml files.
Comment #7
mile23#2853889: Send improved project metadata to testbots was closed in favor of a child issue here: #2909467: Start sending build.yml
We need to formalize how build.yml sends metadata, most importantly project name and type. If we have that information in the build metadata, we don't have to do any work to infer where drupalci.yml would be within the testbot build.
Is there an issue for this that I can't find?
Comment #8
MixologicNo, but it is kindof exactly what Im working on at the moment. I deployed the build.yml changes yesterday, and now, Im going through the code and polishing things up a bit.
So, in the interests of keeping things where they already are, the CodebaseBuildStage plugin already houses that metadata, but Im adjusting how it gets set:
http://cgit.drupalcode.org/drupalci_testbot/tree/src/DrupalCI/Plugin/Bui...
Right now there's still some nonsense about parsing DCI_Testitem, which Im planning on doing away with.
Also, that 'project_subdir' is sortof an artifact of drupal.org not really knowing where the extension actually gets installed to - so thats going to go away, and we'll stop using it, and its cousins "get/setExtensionProjectSubdir" -> which were always really just the "What drupal.org told us, which we use to figure out which one of the DCI_AdditionalRepositories we care about"
So, getTrueExtensionSubDirectory() is really the right way to infer where the drupalci.yml file would be within the build. Except we still have that little sticky thing of "where does core want this file to live? in '/core' or in '/' ?
Comment #9
mile23Right, so how about d.o has a text field where you say: This is the directory in your project where all the QA config will live. Core can put core/ in there, and other projects could put config/ or build/ or whatever they want or just leave it blank for the root directory.
Then this is metadata that comes with build.yml.
Comment #10
MixologicAdded #2951863: Clean up build.yml
Re: text field that feels overconfigurable, so I'd rather we just say "it goes in the root directory, unless you're core, then it goes in /core"
Comment #11
Mixologicrepository inspector is now deployed.
Comment #12
MixologicComment #13
mile23Needed a link from here to there.
Comment #14
MixologicComment #15
MixologicComment #16
MixologicI really wish that closed (fixed) was green instead of red. That doesnt make any sense at all to me why we have 'fixed' and 'closed (fixed)'. And that they're two different colors. Maybe a darker green would be better. (not to mention colorblindness, so probably red/blue would be better)
Anyhow, a *lot* of progress has been made.
Comment #17
MixologicAllrighty. So, we're almost done except for the documenting.
Some decisions that are going into this:
The fetch and patch plugins could both use work, because they are both something that project maintainers could use - maybe they want to test with more than one patch, or maybe they want to patch other modules by default. Also, perhaps their module needs to download a js library to sites/all/libraries - fetch would give a nice api for that.
What I've decided to do in the meantime is not to sharpen this sword until it has a mirrorlike finish, and instead provide what we have now, as is. Both fetch and patch could feasably be implemented using container_command and host_command plugins, so while those will provide a better DX eventually, no need to delay providing at least some form of DX.
So where we are now is
A. Developers can provide a drupalci.yml that will replace the assessment phase of the build.
B. Developers can submit patches that modify the drupalci.yml file, and those patches will affect the build.
C. Developers can run arbitrary commands in the host, and inside the executable container.
All thats really left to do then is
D. Tell developers how to do A, B, and C.
Comment #18
jonathan1055 commentedThis looks very good - thank you for all your efforts.
Looking forward to giving some of this a try, when #17D is done.
I guess that will be on #2949257: Document how to use drupalci.yml in a project
Comment #19
markhalliwellConsidering that documentation has its own issue (#2949257: Document how to use drupalci.yml in a project), I think it's safe to go ahead and mark this issue as "Fixed" since it has actually been implemented. Yay!
Comment #20
mile23Not all the child issues are closed: #2949253: Create a default drupalci.yml with build targets
Edit: Just added #2955706: Create a documented drupalci.yml as a template for users since we postponed adding targets.