Sorry ruby, but chef has got to go.

Apparently chef can't sit on its hands for a few months without breaking itself.  Out you go!  Once removed, there isn't much argument for ruby either: the next best provisioning tool for this use case is probably shell scripts.

This prompts a number of not-so-small changes:
* `make` is now the build tool.
* Rspec and serverspec is likewise abandoned for [`bats`][1], a bash testing tool.
* Version commit/tag management has been extracted to `bump-version`.
* Ditch Ubuntu 14 for 16.
* Ditch VMware, which has [problems][2] in the fuse-based shared FS, for virtualbox

The move to ubuntu 16 was prompted by wanting a newer GPG toolchain (2.1).  However GPG is no longer interesting, as cleanly exposing signing abilities to git within the guest is just too clumsy.  We keep ubuntu 16 since it's the future anyhow.

My previous adherence to ubuntu 14 was driven by a problem between `vagrant-cachier` and permissions/ownership problems appearing in 16.  These have been [resolved][3].

[1]: https://github.com/sstephenson/bats
[2]: vmware/open-vm-tools#90
[3]: fgrehm/vagrant-cachier#175

.editorconfig

@@ -1,4 +1,4 @@
-# This file is managed by chef, changes will be overwritten
+# This file is managed by infrastructure, changes will be overwritten
 
 root = true
 

.gitignore

@@ -1,12 +1,5 @@
 .vagrant
-
-# Bundler
-.bundle/*
-bin/*
-Gemfile.lock
-
-# Berks
-Berksfile.lock
+bin
 
 # Sublime Text
 *.sublime-workspace

.gitmodules

@@ -0,0 +1,3 @@
+[submodule "vendor/bats"]
+	path = vendor/bats
+	url = https://github.com/sstephenson/bats.git

.travis.yml

@@ -1,21 +1,8 @@
 sudo: true
 dist: trusty
-language: ruby
-addons:
-  apt:
-    sources:
-    - chef-current-trusty
-    packages:
-    - chefdk
-before_install:
-- |
-  eval "$(/opt/chefdk/bin/chef shell-init bash)"
-  which ruby
-  ruby --version
-  which bundle
-  bundle --version
-  which gem
-  gem --version
+language: c
+install: bash provisioning/travis
+script: make travis
 deploy:
   provider: releases
   api_key:

Makefile

@@ -0,0 +1,10 @@
+SHELL = /bin/bash
+
+default: tests
+
+travis: tests
+
+tests: integration
+
+integration:
+	vendor/bats/bin/bats test/integration

README.md

@@ -10,46 +10,50 @@ Cross-repository Services
 
 ## About
 
-Infrastructure's goal is to keep the Way development environments consistent across the repos of the organization.  It aims to do so by extracting their provisioning to a single place.  Hand in hand with this goal is automating the process of creating a new repo in the organization.
+Infrastructure's goal is to keep the Way development environments consistent across the repositories of the organization.  It aims to do so by moving common aspects of their provisioning to a single place.  Hand in hand with this goal is automating common life cycle tasks, including creating a new repository in the organization.
 
-There is a natural trade-off between similarity (for portable UX) and diversity (for achieving required function) of org repos.  Infrastructure takes the following stance:
-* All repos will avoid a thick host OS tool chain by sand-boxing development within vagrant.
-* All repos will use ruby and its ecosystem (e.g. rake) for tooling where possible.
-* All repos will automate development environment provisioning with chef.
-* Infrastructure will clearly divide maintenance responsibility of common files, and all repos will respect this division of responsibility.
+In organiaztion repositories there is a natural tension between similarity (for a portable developer experience) and diversity (for achieving required function).  Infrastructure takes the following stance:
+* All repositories will avoid a thick host OS tool chain by sand-boxing development within [vagrant][vagrant].
+* All repositories will automate development environment provisioning with bash.
+* Infrastructure will clearly divide maintenance responsibility of common files, and all repositories will respect this division.
 
 The first point seeks to limit host OS dependencies to:
-* git
-* vagrant
-* text editor of choice
+* `bash`
+* `gpg` or `gpg2` (only needed to tag releases)
+* `git`
+* `vagrant`
+* [`virtualbox`][virtualbox]
+* your text editor of choice
 
-The goal of the last point is to avoid code rot introduced by projects being created at various times in the face of evolving project templates.  When a significantly complex file changes in a way that all repos should consume, infrastructure will roll the change out (e.g. as an updated chef template.)
+The goal of the last point is to avoid code rot introduced by projects being created at various times in the face of evolving project templates.  When a significantly complex file changes in a way that all repositories should consume, infrastructure will roll the change out, e.g. as an updated template.
 
-Infrastructure makes an effort to allow client repositories to retain ownership of most files.  Infrastructure implements two strategies for managing the portions of those files that it owns.  First, it tries to offer an inclusion mechanism of some sort either native to the file format or via a chef partial template.  When inclusion is not appropriate, it falls back to validating client-owned files at provision time to ensure that required features are present (see `project_spec.rb`.)
+Infrastructure makes an effort to allow client repositories to retain ownership of most files.  Infrastructure implements two strategies for managing the portions of those files that it owns.  First, it tries to offer an inclusion mechanism of some sort.  When inclusion is not appropriate, it falls back to validating client-owned files during test to ensure that required features are present (see `layout.bats`).
 
-Infrastructure explicitly does not require:
-* Committing to a host OS (in theory)
-* Committing to an editor, though [editorconfig][editorconfig] users will benefit.
-* Committing to or automating the configuration of external services such as travis CI.
+Infrastructure explicitly does not:
+* Require a particular host OS (in theory)
+* Require an editor, though [editorconfig][editorconfig] users will benefit.
+* Require or automate the configuration of external services such as continuous integration.
 
+[vagrant]: https://www.vagrantup.com/
+[virtualbox]: https://www.virtualbox.org/
 [editorconfig]: http://editorconfig.org/
 
 ## Creating a new Repository
 
-First, make a new way repo in the Github UI.  Then:
+First, make a new way repository in the Github UI.  Then:
 
 ```
 git clone [email protected]:waylang/new_repo.git
 cd new_repo
 curl -s https://raw.githubusercontent.com/waylang/infrastructure/master/install | bash
 ```
 
-This fetches the latest [github release][github-releases] of infrastructure, which generates a Vagrantfile and drops into chef provisioning to create the rest of the project template.  You will be left with some files to commit in your staging area, and a running vagrant instance.
+This fetches the latest [github release][github-releases] of infrastructure, which generates a `Vagrantfile` and drops into provisioning to create the rest of the project template.  You will be left with some files to commit in your staging area, and a running vagrant instance.
 
 [github-releases]: https://help.github.com/articles/about-releases/
 
 ## Releasing a new Version
 
-Use the `version:major`, `version:minor` and `version:patch` rake tasks to bump the given semantic version component.  This will create a new commit (modifying the `version` file) and an annotated tag.  The tag is not automatically pushed.
+Use `./bin/bump-version` with `major`, `minor` or `patch` arguments to bump the given semantic version component.  This will modify the `version` file in a new commit and add a gpg-signed, annotated tag.  Neither the commit nor the tag is not automatically pushed.
 
 It is expected that the repository's CI service will trigger a build in response to pushing the tag and, if the build succeeds, release the new version using the appropriate continuous delivery process.

Vagrantfile

@@ -1,22 +1,16 @@
-require 'ostruct'
-require 'pathname'
-
 Vagrant.configure('2') do |config|
   if Vagrant.has_plugin?('vagrant-cachier')
-    config.cache.scope = :box # http://fgrehm.viewdocs.io/vagrant-cachier/usage/
+    config.cache.scope = :box
+    config.cache.synced_folder_opts = {
+      owner: '_apt',
+      group: '_apt'
+    }
   end
 
-  config.vm.box = 'ubuntu/trusty64'
+  config.vm.box = 'box-cutter/ubuntu1604'
   config.vm.hostname = 'infrastructure'
   config.ssh.forward_agent = true
 
-  %w(vmware_fusion vmware_workstation).each do |vmware|
-    config.vm.provider vmware do |provider, override|
-      provider.name = 'infrastructure'
-      override.vm.box = 'netsensia/ubuntu-trusty64'
-    end
-  end
-
   config.vm.provider 'virtualbox' do |provider, _override|
     provider.name = 'infrastructure'
   end
@@ -25,20 +19,13 @@ Vagrant.configure('2') do |config|
     config.vm.provision :file, source: '~/.gitconfig', destination: '.gitconfig'
   end
 
-  config.vm.provision :shell, inline: %(
-which chef || wget -qO - https://www.chef.io/chef/install.sh | bash -s -- -P chefdk
-berks vendor -b /vagrant/Berksfile /tmp/vagrant-chef/cookbooks
-)
-
-  config.vm.provision :chef_solo do |chef_solo|
-    chef_solo.install = false
-    chef_solo.binary_path = '/opt/chefdk/bin'
-    chef_solo.add_recipe 'infrastructure::vagrant'
-  end
-
-  # If Vagrantfile.custom exists, read and eval it in this context
-  vagrant_custom = Pathname.new(__FILE__).parent + 'Vagrantfile.custom'
-  if File.exist?(vagrant_custom)
-    OpenStruct.new(config: config).instance_eval File.read(vagrant_custom)
+  config.vm.provision :shell do |shell|
+    shell.privileged = false
+    shell.keep_color = true
+    shell.path = 'provisioning/vagrant'
+    shell.env = {
+      PROJECT_DIR: '/vagrant',
+      PROJECT_NAME: 'infrastructure'
+    }
   end
 end