This change creates a scripts/ folder, moves our existing shell
script, gocover.sh, underneath it, and factors the publish logic
out of the Makefile and into the publish.sh file.
The syntax for sed differs between Mac OS X and GNU versions of
the tool, which is rather annoying. This fixes it by leveraging
the fact that `sed -i.bak ...` works, although we now need to
clean up the *.bak file left behind. (No big deal and way better
than maintaining OS-dependent logic.)
This adds a new make target, publish, that will create a release
package and upload it to an S3 bucket. This package simply contains
the built CLI plus the core library packages, lumi, lumirt, and lumijs.
This target is invoked automatically at the end of a successful
Travis run against a push to master.
Adds a make task to generate code coverage for all Go sources.
That make task re-runs the tests, and can be fairly expensive,
so it is enabled only in the nightly tests for now.
Part of #206.
This should fix the issues with escaping in Travis (fingers crossed).
Also specifies the -e flag for echo, since switching the shell to
bash led to ANSI escape codes being uninterpreted by default.
This change fixes a few things:
* Most importantly, we need to place a leading "." in the paths
to Gometalinter, otherwise some sub-linters just silently skip
the directory altogether. errcheck is one such linter, which
is a very important one!
* Use an explicit Gometalinter.json file to configure the various
settings. This flips on a few additional linters that aren't
on by default (line line length checking). Sadly, a few that
I'd like to enable take waaaay too much time, so in the future
we may consider a nightly job (this includes code similarity,
unused parameters, unused functions, and others that generally
require global analysis).
* Now that we're running more, however, linting takes a while!
The core Lumi project now takes 26 seconds to lint on my laptop.
That's not terrible, but it's long enough that we don't want to
do the silly "run them twice" thing our Makefiles were previously
doing. Instead, we shall deploy some $$($${PIPESTATUS[1]}-1))-fu
to rely on the fact that grep returns 1 on "zero lines".
* Finally, fix the many issues that this turned up.
I think(?) we are done, except, of course, for needing to drive
down some of the cyclomatic complexity issues (which I'm possibly
going to punt on; see pulumi/lumi#259 for more details).
This disables gotype as a linter, since it depends on object files
in an annoying way (and doesn't add much beyond go build anyway).
From alecthomas/gometalinter#206, it sounds like the current plan
is to remove gotype entirely from the set of linters GML runs.
After 233c5a8 landed, I noticed there are a few things to be fixed up:
* Run gometalinter in all the right places. We need to run both in
lint and lint_quiet targets. I've also cleaned up some of the logic
around what to suppress so there's less repetition.
* We currently @ meaningful commands, which is unfortunate, since it
makes debugging Makefiles tough (especially when looking at CI build
logs). Going forward, we should only use @ for meaningless commands,
like @echo.
* The AWS project wasn't actually running tslint, because it needs to
say `tslint './pack/**/*.ts' --exclude='./pack/node_modules/**'`.
The current script of `tslint lib/aws/pack/...` wasn't actually
running lint, hence we missed a lot of AWS lint issues.
* Fix up the issues that these fixes uncovered. Mostly err shadowing.
Make nightly tests more verbose to avoid 10 minute
timeout in Travis when we have no test output.
Run aws provider tests by default again on full builds.
Adds a nightly build target that runs the long running provider
and examples tests. Enables travis to run this on cron jobs,
which we will configure to trigger nightly.
Tests all of our commonly used examples.
Also sets test parallelism to 10 by default
since we are I/O bound on API calls to
the resource providers.
Also avoids using larger EC2 examples in
our samples so that we can keep our test
costs lower :-).
This change splits the core Lumi library -- which is meant to be a pure
LumiJS library without any special status -- from the runtime library --
which is really meant to be the underpinnings of "special" functionality
that integrates with the runtime in sophisticated ways.
After this change, LumiRT is at the very bottom, and, despite it using
a subset of LumiJS, it must not trigger any functionality that would
mandate the use of the LumiJS runtime library. Atop that, the LumiJS
library is layered. And finally, above that, Lumi depends on LumiJS.
In the places we run `go build`, we should use
`go build -i` to save the `.a` files generated
during the build. This ensures the artifacts
are availble for other Go tools (linters, IDEs), and
should also improve build speeds.
This change eliminates the use of nonstandard tools in our build:
* `go test` automatically uses `GOMAXPROCS` for its parallelism
setting. In modern Go, this is now set to the number of processors.
So, there is no need to set it explicitly using `nproc`.
* We can avoid `realpath` in the `lumijs` executable by making it
a Node.js file and using a relative require import of main.
* We can avoid `realpath` in our Makefiles by just using `pwd`.
* Makeify more; add a "full build" target
This change uses make for more of our tree. Namely, the AWS provider
and LumiJS compilers each now use make to build and/or install them.
Not only does this bring about some consistency to how we build and
test things, but also made it easy to add a full build target:
$ make all
This target will build, test, and install the core Go tools, the LumiJS
compiler, and the AWS provider, in that order.
Each can be made in isolation, however, which ensures that the inner
loop for those is fast and so that, when it comes to finishing
pulumi/lumi#147, we can easily split them out and make from the top.
The AWS tests take a while to run and it's easy to forget. Further,
they are going to start taking quite a bit longer very soon.
So, this change introduces a `make full` target, which is what our
CI tests run. But the ordinary `make` skips the long tests for faster
inner loop verification. Over time, I'm sure we'll get far more
sophisticated with the split between inner vs. outer loop testing,
especially for performance, stress, and so on.
Golint by default doesn't return a non-zero exit code when lint errors
are present. To address this, we need to pass -set_exit_status.
But it gets more complicated: because we are suppressing some lint
warnings, we cannot use -set_exit_status in the lint_quiet target.
For that, we use test -z to fail if any output passes the filter.
Eventually when we do pulumi/lumi#191, we can remove this hack.
This change enables parallelism for our tests.
It also introdues a `test_core` Makefile target to just run the
core engine tests, and not the providers, since they take a long time.
This is intended only as part of the inner developer loop.
Due to https://github.com/golang/go/issues/12294, our Travis jobs are
failing with
pkg/compiler/binder/stmtexpr.go:160: no formatting directive in Errorf call
etc, etc. Perplexingly, this is supposedly fixed as of Go 1.7.5, and we are
running Go 1.8.2 in Travis. However, vet is a separate binary tool, so it seems
either (1) Go's Linux distro doesn't contain the right version or (2) Travis's
image doesn't contain the right version. I have to imagine (2) is more likely,
except that I can't actually look at the machine (and go vet doesn't have a version)!
For now, we will just skip the -printf checks.
This change keeps the lumi prefix on our CLI tools.
As @lukehoban pointed out in person, as soon as we do pulumi/coconut#98,
most people (other than compiler authors themselves) won't actually be
typing the commands. And, furthermore, the commands aren't all that bad.
Eventually I assume we'll want something like `lumi-js`, or
`lumi-js-compiler`, so that binaries are discovered dynamically in a way
that is extensible for future languages. We can tackle this during #98.
This change runs golint during make by default, but suppresses the
class of errors we are currently permitting into the code (just those
about public documentation on APIs).
This change restructures the overall structure for commands so that
all top-level tools are in the cmd/ directory, alongside the primary
coco command. This is more "idiomatic Go" in its layout, and makes
room for additional command line tools (like cocogo for IDL).
This adds a bunch of independent targets to the Makefile, to help
run individual commands as needed. It also skips running `golint`
by default (per golint's advice, actually), because it spews lots
of documentation-related things at the moment, which we are
intentionally ignoring. (Mainly just hundreds of public members
without comments; eventually we'll need to tackle this.)
This adds a bunch of general scaffolding and the beginning of a `build` command.
The general engineering scaffolding includes:
* Glide for dependency management.
* A Makefile that runs govet and golint during builds.
* Google's Glog library for logging.
* Cobra for command line functionality.
The Mu-specific scaffolding includes some packages:
* mu/pkg/diag: A package for compiler-like diagnostics. It's fairly barebones
at the moment, however we can embellish this over time.
* mu/pkg/errors: A package containing Mu's predefined set of errors.
* mu/pkg/workspace: A package containing workspace-related convenience helpers.
in addition to a main entrypoint that simply wires up and invokes the CLI. From
there, the mu/cmd package takes over, with the Cobra-defined CLI commands.
Finally, the mu/pkg/compiler package actually implements the compiler behavior.
Or, it will. For now, it simply parses a JSON or YAML Mufile into the core
mu/pkg/api types, and prints out the result.