pre load Drupal 7 platform

[niccolox]

would be good if there was a D7 platform provisioned in Valkyrie as part of installation

this is one of the big selling points on BOA

[ergonlogic]

The hostmaster platform is already a D7. If anything, we'd probably build a Rune platform. But we already provide commands to create such platforms easily (drush vsg), so I don't see a lot of benefit to doing so when instantiating a project.

[niccolox]

interesting

created a Rune site using the make in the Valkyrie web ui

https://raw.githubusercontent.com/poetic/rune/master/makefiles/stubs/dev.make.yml

would be interested to learn how Valkyrie & Gitalb are used together

the workflow for developing a site

i.e. now I have created a site using make, do I then git init in that platform folder ?

etc... thats obviously a separate Issue https://github.com/GetValkyrie/valkyrie/issues/45

[niccolox]

https://github.com/GetValkyrie/valkyrie/issues/45 Valkyrie, Rune & Gitlab

[MatthewHager]

I'd actually also like to see it spin up with a copy of Rune ready to go. We'll never spin up a copy and not use Rune so I don't see why not to just include it. For the few that don't end up using Rune, we'll just make an option to spin up a copy of valkyrie and skip the role that handles that.

In the end, Rune will end up complimenting Valkyrie so much so that I expect many others outside our organization to use it because of all the patches and things we did in order to get a true git based workflow going.

[niccolox]

I think thats a great idea

its a nice distro and I do think having a distro loaded up ready to go completes the mission of the project

[ergonlogic]

I see your point, but I see Valkyrie as more 'project'-oriented.

That is, a "project" represents a discrete site (or network of sites) under development. Multiple projects are handled by only working on one at a time, and vagrant halting projects that aren't actively being worked on. To move to another project, you halt the one you're currently working on, and up the one to which you're moving. This saves us a tonne of head-aches trying to support multiple active projects at once; allowing us to re-use our core Drush aliases, for example.

As such, I don't see platforms as the foundational element on which we're working within the dev environment of the Valkyrie system. It seems like sites are what we're building. So, while building a platform will help bootstrap a given project, most collaborators will be cloning a site. For a site that's already in development (or QA, staging, or production), the makefile for the platform on which it'll run should be included, like a gemfile, within the site repo itself. This makes the site repo self-contained and portable.

This is already how drush vsc works, as it'll look for a platform.make in the root of your site's repo, then builds a platform and installs the site on it. drush vnew could easily enough do the same, by simply calling valkyrie-site-clone (vsc) where it currently ends. But then, vsc already calls valkyrie-platform-generate, so it could call vnew too. That seems to make more sense, actually....

So, yes, build a Rune platform on drush vnew by default (i.e., when the project is 'new'), but make platform-generation optional. That way, when a project has already been bootstrapped, instead of vnew, you call vsc, which will build a new project (vm, etc.), as well as a new platform, etc. if none yet exist, but use and existing project and platform if one or both are available.

I'm not entirely sure that all makes sense, but I'm not averse to building a default platform. In fact, it should be pretty easy. Just re-use what we do here: https://github.com/GetValkyrie/valkyrie/blob/0.4.x/valkyrie.drush.inc#L574

[ergonlogic]

Just a note: don't think I under-estimate the value of strong platform management practices, because of the focus I put on site development above. It's just the primary concern in the staging and production environments, more so that dev/testing.

[niccolox]

if there is a drush cli for this, I'd roll that as an optional step in the install docs and it completes the toolchain

from a developer perspective its neat to be able to install, test and compare various distros and get a sense of the modules, themes, config and site building patterns from each

thats one of the things that attracted to me to BOA. having a set of reference distros already installed

[ergonlogic]

Unfortunately, most distros don't appear to include sufficient tooling for a proper, easy git/features-based workflow. Many workflows seem to still sync DBs around. We keep all config in code, and continue to actively work to make Rune support this workflow. Of course, this should all become somewhat easier with CMI in D8.

As such, I don't see us ever building the ~25 platforms that BOA comes with out-of-the-box. Besides, drush @vm vpg --profile=openoutreach oo will generate a makefile for you and build an OpenOutreach platform (called 'oo', in this case).

[MatthewHager]

I forgot about our plans to build a platform when a site is cloned and keep all that packaged. I think we can just make good enough docs to cover this and it'll be fine.

[ergonlogic]

As per the above, it's a one-liner to build a platform with any given profile available. I'd prefer not add the overhead of building a platform (that may never be used) automatically, and optimize for experienced user's use-cases. Good documentation (currently lacking) will be the key here. See: https://github.com/GetValkyrie/valkyrie-docs