nerdstein / bild Goto Github PK

Some projects may want to use MkDocs for managing it's documentation. We could consider a Bild plugin for this.

See issue #9 before proceeding

1. List out modules
2. Commands for grabbing info from Drupal or various other Bild modules to document parts of the project in an automated way

Tokenized / twig based config files

Create a plugin that integrates DrupalVM with your project

To make this tool flexible, I want the project to ship with a base "provisioner" and be extended discretionally thereafter.

The extensions ideally will be managed through Composer, in a similar way to how Robo extensions work. And, most importantly, all extensions should not reinvent the wheel. We should make use of existing Composer and Robo plugins and only write glue code that associates the existing plugins to the outcomes of Bild provisioning.

Links to review:
http://robo.li/extending/
https://github.com/boedah/robo-drush

See issue #9 before proceeding.

Make a Bowline module for Bild based on code found in https://github.com/davenuman/bowline

Meta:
The command, code, and config organization of Bild is far too ad-hoc and thus is confusing.

Introducing "modules", akin to Drupal modules.

Impact:
-Need a "core" module for Project settings (name, etc) which are variables exposed to twig, organized by module
-Install options and arguments for module, populate to broader Twig namespace
-Configuration stubs (twig)
-Documentation stubs (twig)
-Project-level dependencies (no commands will work)
-Command-level soft dependencies to other modules (for manifest "recipes" that have optional functionality ) and a weighting algorithm
-Changes to the installer, make it interactive! Ask for "registered" repos with overridable commands, ask for which non-core Bild sponsored modules people want (automated testing, vm, bowline, etc)
-Changes to the Install Project command, possibly deprecate Initialize project command
-Install Profile (a separate Git repo with install.bild.yml file with only hardcoded settings and annotated modules)
-Custom modules (separate Git repo with some code-level structure)
-Changes to engine.php, only load "relevant" commands both by module and by command-level soft dependency

Steps:
-Branch for current code, 0.x. New work will go in 1.x
-Some sort of plugin system for modules
-Module metadata (dependencies)
-Unclear impact to overriding commands, need more details and research
-Evaluate Drupal modules and generate make file, Composer, node, ruby
-Evaluate module level "install" and "teardown" command reference

Well, I think what Robo could add might be some of the following

grugnog [12:54 PM]
Community

grugnog [12:55 PM]
Less code to maintain (there are existing task runners for several things bldr provides)

grugnog [12:55 PM]
Sequencing - i.e. a concise way to define a series of tasks to run, together with the configuration needed to run them

grugnog [12:56 PM]
Output integration - i.e. capture and (to some extent) standardize the output from diverse task backends

grugnog [12:57 PM]
Built in ability to manage background/parallel tasks (e.g. bringing up phantomjs to run browser tests against) (edited)

grugnog [12:58 PM]
Unit tests for all it's tasks

Based on Symfony.

e.g. a project for contrib repos

Global config
-Git lg
-Show branch on git

How does a plugin manage / update Bild configuration? Or, does it not?

Ideally, there will be the ability for a plugin to say what settings are needed from the bild.yml file.

Maybe this is managed through documentation only with sane defaults if the configuration is not set.

license: proprietary in composer.json may hinder collaboration. 😉

drupal_major_version
drush_version
php_version
solr_version

source in ~/Projects/bild

run bild from ~/Projects and this throws an error