maxmustermann/pulumi
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
pulumi/Makefile

61 lines
1.8 KiB
Makefile
Raw Normal View History

Remove SDK dependencies This change eliminates our dependencies on the SDK repo. Now that SDKs are comprised solely of pulumi/pulumi artifacts, a separate repo isn't required. This allows us to simplify some of the distribution. The install.sh script is modified slightly, to permit overriding the default install location using $PULUMI_INSTALL_PATH.
2018-04-28 22:05:30 +02:00
PROJECT_NAME := Pulumi SDK
Add Makefile machinery for Go provider
2018-06-10 01:16:35 +02:00
SUB_PROJECTS := sdk/nodejs sdk/python sdk/go
Adopt new makefile system See https://github.com/pulumi/home/pull/56 for more details.
2017-11-12 01:20:56 +01:00
include build/common.mk
Install GoMetaLinter in Travis And also rejigger the Makefiles to properly error if it's missing.
2017-06-21 23:23:48 +02:00
Reenable integration tests Because of the way we passed packages to test commands, we were skipping the tests/cloud/ and tests/ints/ tests altogether. This reenables them.
2017-12-05 22:39:13 +01:00
PROJECT := github.com/pulumi/pulumi
PROJECT_PKGS := $(shell go list ./cmd/... ./pkg/... | grep -v /vendor/)
EXTRA_TEST_PKGS := $(shell go list ./examples/ ./tests/... | grep -v /vendor/)
Adopt new version strategy Our previous strategy of just using `git describe --tags --dirty` to compute a version caused issues. The major one was that since version sort lexigrapically, git's strategy of having a commit count without leading zeros lead to cases where 0.11.0-dev-9 was "newer than" 0.11.0-dev-10 which is not what you want at all. With this change, we compute a version by first seeing if the commit is tagged, and if so, we use that tag. Otherwise, we take the closest tag and to it append the unix timestamp of the commit and then append a git hash. Because we use the commit timestamp, things will sort correctly again. Part of pulumi/home#174
2018-03-16 01:07:01 +01:00
VERSION := $(shell scripts/get-version)
Sketch a `mu build` command and its scaffolding 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.
2016-11-15 20:30:34 +01:00
Adopt new makefile system See https://github.com/pulumi/home/pull/56 for more details.
2017-11-12 01:20:56 +01:00
GOMETALINTERBIN := gometalinter
GOMETALINTER := ${GOMETALINTERBIN} --config=Gometalinter.json
Disable gotype linter 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.
2017-06-21 23:46:03 +02:00
Adopt new makefile system See https://github.com/pulumi/home/pull/56 for more details.
2017-11-12 01:20:56 +01:00
TESTPARALLELISM := 10
Install fixed versions of our tools For some tools we used, like `dep` and `gometalinter` we were just calling `go install` which caused us to pick up whatever was in `HEAD` at that time. Now, we move to a model where we install fixed versions, which will change per milestone. While doing this, I changed the way our .travis.yml file runs everything to move as much as possible out into scripts and do so in a way that allows us to share as much common logic across our repositories.
2018-01-24 00:56:58 +01:00
# Our travis workers are a little show and sometime the fast tests take a little longer
ifeq ($(TRAVIS),true)
TEST_FAST_TIMEOUT := 10m
else
Bump the test timeout in CI. Parameterize the timeout for the fast tests with a default of 2 minutes that is bumped to 10 minutes in CI due to slow I/O during macOS builds.
2017-12-15 21:12:06 +01:00
TEST_FAST_TIMEOUT := 2m
Install fixed versions of our tools For some tools we used, like `dep` and `gometalinter` we were just calling `go install` which caused us to pick up whatever was in `HEAD` at that time. Now, we move to a model where we install fixed versions, which will change per milestone. While doing this, I changed the way our .travis.yml file runs everything to move as much as possible out into scripts and do so in a way that allows us to share as much common logic across our repositories.
2018-01-24 00:56:58 +01:00
endif
Add nightly build target 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.
2017-06-16 18:50:56 +02:00
Adopt new makefile system See https://github.com/pulumi/home/pull/56 for more details.
2017-11-12 01:20:56 +01:00
build::
Add a manifest to checkpoint files (#630) This change adds a new manifest section to the checkpoint files. The existing time moves into it, and we add to it the version of the Pulumi CLI that created it, along with the names, types, and versions of all plugins used to generate the file. There is a magic cookie that we also use during verification. This is to help keep us sane when debugging problems "in the wild," and I'm sure we will add more to it over time (checksum, etc). For example, after an up, you can now see this in `pulumi stack`: ``` Current stack is demo: Last updated at 2017-12-01 13:48:49.815740523 -0800 PST Pulumi version v0.8.3-79-g1ab99ad Plugin pulumi-provider-aws [resource] version v0.8.3-22-g4363e77 Plugin pulumi-langhost-nodejs [language] version v0.8.3-79-g77bb6b6 Checkpoint file is /Users/joeduffy/dev/code/src/github.com/pulumi/pulumi-aws/.pulumi/stacks/webserver/demo.json ``` This addresses pulumi/pulumi#628.
2017-12-01 22:50:32 +01:00
go install -ldflags "-X github.com/pulumi/pulumi/pkg/version.Version=${VERSION}" ${PROJECT}
Clean up the Makefile 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.)
2017-01-28 00:42:55 +01:00
Adopt new makefile system See https://github.com/pulumi/home/pull/56 for more details.
2017-11-12 01:20:56 +01:00
install::
Add a manifest to checkpoint files (#630) This change adds a new manifest section to the checkpoint files. The existing time moves into it, and we add to it the version of the Pulumi CLI that created it, along with the names, types, and versions of all plugins used to generate the file. There is a magic cookie that we also use during verification. This is to help keep us sane when debugging problems "in the wild," and I'm sure we will add more to it over time (checksum, etc). For example, after an up, you can now see this in `pulumi stack`: ``` Current stack is demo: Last updated at 2017-12-01 13:48:49.815740523 -0800 PST Pulumi version v0.8.3-79-g1ab99ad Plugin pulumi-provider-aws [resource] version v0.8.3-22-g4363e77 Plugin pulumi-langhost-nodejs [language] version v0.8.3-79-g77bb6b6 Checkpoint file is /Users/joeduffy/dev/code/src/github.com/pulumi/pulumi-aws/.pulumi/stacks/webserver/demo.json ``` This addresses pulumi/pulumi#628.
2017-12-01 22:50:32 +01:00
GOBIN=$(PULUMI_BIN) go install -ldflags "-X github.com/pulumi/pulumi/pkg/version.Version=${VERSION}" ${PROJECT}
Track resources that are pending deletion in checkpoints. During the course of a `pulumi update`, it is possible for a resource to become slated for deletion. In the case that this deletion is part of a replacement, another resource with the same URN as the to-be-deleted resource will have been created earlier. If the `update` fails after the replacement resource is created but before the original resource has been deleted, the snapshot must capture that the original resource still exists and should be deleted in a future update without losing track of the order in which the deletion must occur relative to other deletes. Currently, we are unable to track this information because the our checkpoints require that no two resources have the same URN. To fix this, these changes introduce to the update engine the notion of a resource that is pending deletion and change checkpoint serialization to use an array of resources rather than a map. The meaning of the former is straightforward: a resource that is pending deletion should be deleted during the next update. This is a fairly major breaking change to our checkpoint files, as the map of resources is no more. Happily, though, it makes our checkpoint files a bit more "obvious" to any tooling that might want to grovel or rewrite them. Fixes #432, #387.
2017-10-05 23:08:35 +02:00
Rename `lint_quiet` to `lint` We have some lint debt (around exported functions being underdocumented) so we have a custom target that ignores some lint warnings. However, that target (which is the only lint target that needs to be clean to check in) is called `lint_quiet` instead of `lint` which is our normal linting target. Rename the target so your fingers can learn that `make lint` is always the right way to run linting before checkin.
2017-11-01 00:39:23 +01:00
LINT_SUPPRESS="or be unexported"
Adopt new makefile system See https://github.com/pulumi/home/pull/56 for more details.
2017-11-12 01:20:56 +01:00
lint::
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
$(GOMETALINTER) main.go | grep -vE ${LINT_SUPPRESS} | sort ; exit $$(($${PIPESTATUS[1]}-1))
Tidy up more lint 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).
2017-06-22 21:09:46 +02:00
$(GOMETALINTER) ./pkg/... | grep -vE ${LINT_SUPPRESS} | sort ; exit $$(($${PIPESTATUS[1]}-1))
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
$(GOMETALINTER) ./cmd/... | grep -vE ${LINT_SUPPRESS} | sort ; exit $$(($${PIPESTATUS[1]}-1))
Clean up the Makefile 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.)
2017-01-28 00:42:55 +01:00
Adopt new makefile system See https://github.com/pulumi/home/pull/56 for more details.
2017-11-12 01:20:56 +01:00
test_fast::
Bump the test timeout in CI. Parameterize the timeout for the fast tests with a default of 2 minutes that is bumped to 10 minutes in CI due to slow I/O during macOS builds.
2017-12-15 21:12:06 +01:00
go test -timeout $(TEST_FAST_TIMEOUT) -cover -parallel ${TESTPARALLELISM} ${PROJECT_PKGS}
Make all by default
2017-08-06 17:52:32 +02:00
Adopt new makefile system See https://github.com/pulumi/home/pull/56 for more details.
2017-11-12 01:20:56 +01:00
test_all::
Reenable integration tests Because of the way we passed packages to test commands, we were skipping the tests/cloud/ and tests/ints/ tests altogether. This reenables them.
2017-12-05 22:39:13 +01:00
PATH=$(PULUMI_ROOT)/bin:$(PATH) go test -cover -parallel ${TESTPARALLELISM} ${EXTRA_TEST_PKGS}
Makeify more; add a "full build" target (#193) * 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.
2017-06-02 23:26:34 +02:00
Publish tgz's in the middle of the build, packages at the end While it's safe to publish the tgz that we use internally for other repositories that are on "the link plan" after the build completes, we shouldn't publish packages to NPM and PyPi at that point. There are two reasons for doing this: 1. Publishing packages before they are tested, which means we could end up publishing packages that don't work. 2. NPM prevents publishing the same package more than once, so if we had to re-run the job (due to tests failing for transient issues), the publish step will start failing, preventing us from running the tests at all.
2018-03-06 23:36:50 +01:00
.PHONY: publish_tgz
publish_tgz:
Adopt new makefile system See https://github.com/pulumi/home/pull/56 for more details.
2017-11-12 01:20:56 +01:00
$(call STEP_MESSAGE)
Publish tgz's in the middle of the build, packages at the end While it's safe to publish the tgz that we use internally for other repositories that are on "the link plan" after the build completes, we shouldn't publish packages to NPM and PyPi at that point. There are two reasons for doing this: 1. Publishing packages before they are tested, which means we could end up publishing packages that don't work. 2. NPM prevents publishing the same package more than once, so if we had to re-run the job (due to tests failing for transient issues), the publish step will start failing, preventing us from running the tests at all.
2018-03-06 23:36:50 +01:00
./scripts/publish_tgz.sh
.PHONY: publish_packages
publish_packages:
$(call STEP_MESSAGE)
./scripts/publish_packages.sh
Sketch a `mu build` command and its scaffolding 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.
2016-11-15 20:30:34 +01:00
Adopt new makefile system See https://github.com/pulumi/home/pull/56 for more details.
2017-11-12 01:20:56 +01:00
.PHONY: coverage
coverage:
$(call STEP_MESSAGE)
Fix coverage build
2017-11-20 20:12:04 +01:00
./scripts/gocover.sh
Add Go code coverage reports to nightly tests 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.
2017-06-24 00:11:20 +02:00
Use explicit targets in Makefile for Travis Defer build and publish logic into the makefiles instead of trying to use Travis to do so. This let's us sidestep Travis's not great error handling (see pulumi/home#21 for more details)
2017-09-28 20:53:08 +02:00
# The travis_* targets are entrypoints for CI.
Adopt new makefile system See https://github.com/pulumi/home/pull/56 for more details.
2017-11-12 01:20:56 +01:00
.PHONY: travis_cron travis_push travis_pull_request travis_api
travis_cron: all coverage
Publish tgz's in the middle of the build, packages at the end While it's safe to publish the tgz that we use internally for other repositories that are on "the link plan" after the build completes, we shouldn't publish packages to NPM and PyPi at that point. There are two reasons for doing this: 1. Publishing packages before they are tested, which means we could end up publishing packages that don't work. 2. NPM prevents publishing the same package more than once, so if we had to re-run the job (due to tests failing for transient issues), the publish step will start failing, preventing us from running the tests at all.
2018-03-06 23:36:50 +01:00
travis_push: only_build publish_tgz only_test publish_packages
Use explicit targets in Makefile for Travis Defer build and publish logic into the makefiles instead of trying to use Travis to do so. This let's us sidestep Travis's not great error handling (see pulumi/home#21 for more details)
2017-09-28 20:53:08 +02:00
travis_pull_request: all
travis_api: all
Reference in a new issue Copy permalink