Go to file
joeduffy 289a0d405d Revive some compiler tests
This change revives some compiler tests that are still lingering around
from the old architecture, before our latest round of ship burning.

It also fixes up some bugs uncovered during this:

* Don't claim that a symbol's kind is incorrect in the binder error
  message when it wasn't found.  Instead, say that it was missing.

* Do not attempt to compile if an error was issued during workspace
  resolution and/or loading of the Mufile.  This leads to trying to
  load an empty path and badness quickly ensues (crash).

* Issue an error if the Mufile wasn't found (this got lost apparently).

* Rename the ErrorMissingPackageName message to ErrorInvalidPackageName,
  since missing names are now caught by our new fancy decoder that
  understands required versus optional fields.  We still need to guard
  against illegal characters in the name, including the empty string "".

* During decoding, reject !src.IsValid elements.  This represents the
  zero value and should be treated equivalently to a missing field.

* Do not permit empty strings "" as Names or QNames.  The old logic
  accidentally permitted them because regexp.FindString("") == "", no
  matter the regex!

* Move the TestDiagSink abstraction to a new pkg/util/testutil package,
  allowing us to share this common code across multiple package tests.

* Fix up a few messages that needed tidying or to use Infof vs. Info.

The binder tests -- deleted in this -- are about to come back, however,
I am splitting up the changes, since this represents a passing fixed point.
2017-01-26 15:30:08 -08:00
cmd Revive some compiler tests 2017-01-26 15:30:08 -08:00
docs Add a pretty little picture 2017-01-26 08:27:53 -08:00
examples Add a example web crawler Mu blueprint 2017-01-12 14:59:18 -08:00
lib Rearrange the library code 2017-01-20 10:30:43 -08:00
pkg Revive some compiler tests 2017-01-26 15:30:08 -08:00
tools/mujs Add instructions for building and testing MuJS 2017-01-26 13:39:33 -08:00
.gitignore Move all cloud switching to mu/x MuPackage 2017-01-20 09:46:59 -08:00
.gitmodules Add Docker Compose and Kubernetes conversions as submodules 2016-11-01 10:30:39 -07:00
glide.lock Switch back to the official YAML repo 2016-12-09 11:59:05 -08:00
glide.yaml Switch back to the official YAML repo 2016-12-09 11:59:05 -08:00
main.go Move glogging into Mu command startup/teardown 2016-11-19 16:42:27 -08:00
Makefile Test packages when making the project 2016-11-15 19:25:06 -08:00
README.md Add a note about debugging 2017-01-26 13:50:27 -08:00

Mu

Mu is a framework and toolset for creating reusable stacks of services.

If you are learning about Mu for the first time, please see the overview document.

Architecture

Architecture

Building and Testing

To build Mu, first clone it into a standard Go workspace:

$ mkdir -p $GOPATH/src/github.com/marapongo
$ git clone git@github.com:marapongo/mu $GOPATH/src/github.com/marapongo/mu

A good default value for GOPATH is ~/go.

Mu needs to know where to look for its runtime, library, etc. By default, it will look in /usr/local/mu, however you can override this with the MUPATH variable. Normally it's easiest just to create a symlink:

$ ln -s $GOPATH/src/github.com/marapongo/mu /usr/local/mu

There is one additional build-time dependency, golint, which can be installed using:

$ go get -u github.com/golang/lint/golint

And placed on your path by:

$ export PATH=$PATH:$GOPATH/bin

At this point you should be able to build and run tests from the root directory:

$ cd $GOPATH/src/github.com/marapongo/mu
$ make

This installs the mu binary into $GOPATH/bin, which may now be run provided make exited successfully.

Debugging

The Mu tools have extensive logging built in. In fact, we encourage liberal logging in new code, and addding new logging when debugging problems. This helps to ensure future debugging endeavors benefit from your sleuthing.

All logging is done using Google's Glog library. It is relatively barebones, and adds basic leveled logging, stack dumping, and other capabilities beyond what Go's built-in logging routines offer.

The Mu command line has two flags that control this logging and that can come in handy when debugging problems. The --logtostderr flag spews directly to stderr, rather than the default of logging to files in your temp directory. And the --verbose=n flag (-v=n for short) sets the logging level to n. Anything greater than 3 is reserved for debug-level logging, greater than 5 is going to be quite verbose, and anything beyond 7 is extremely noisy.

For example, the command

$ mu compile blueprint.yaml --logtostderr -v=5

is a pretty standard starting point during debugging that will show a fairly comprehensive trace log of a compilation.