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

86 lines
3.4 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 **preview** .NET Core support for pulumi. (#3399)
2019-10-26 01:59:50 +02:00
SUB_PROJECTS := sdk/dotnet 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
remove reference to ./cmd/... in build scripts
2020-03-18 21:37:35 +01:00
PROJECT_PKGS := $(shell go list ./pkg/... | grep -v /vendor/)
Speed up the test runs (#3254) * Faster test runs * Remove template tests from all but cron runs
2019-09-23 19:10:11 +02:00
EXTRA_TEST_PKGS := $(shell go list ./examples/ ./tests/... | grep -v tests/templates | grep -v /vendor/)
Add publishing to nuget support (#3416)
2019-10-30 04:14:49 +01:00
VERSION := $(shell scripts/get-version HEAD)
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
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
update builds to handle new go mod layout
2020-03-19 00:41:23 +01:00
ensure::
$(call STEP_MESSAGE)
ifeq ($(NOPROXY), true)
@echo "cd sdk && GO111MODULE=on go mod tidy"; cd sdk && GO111MODULE=on go mod tidy
@echo "cd sdk && GO111MODULE=on go mod vendor"; cd sdk && GO111MODULE=on go mod vendor
@echo "cd pkg && GO111MODULE=on go mod tidy"; cd pkg && GO111MODULE=on go mod tidy
@echo "cd pkg && GO111MODULE=on go mod vendor"; cd pkg && GO111MODULE=on go mod vendor
@echo "cd examples && GO111MODULE=on go mod tidy"; cd examples && GO111MODULE=on go mod tidy
@echo "cd examples && GO111MODULE=on go mod vendor"; cd examples && GO111MODULE=on go mod vendor
@echo "cd tests && GO111MODULE=on go mod tidy"; cd tests && GO111MODULE=on go mod tidy
@echo "cd tests && GO111MODULE=on go mod vendor"; cd tests && GO111MODULE=on go mod vendor
else
@echo "cd sdk && GO111MODULE=on GOPROXY=$(GOPROXY) go mod tidy"; cd sdk && GO111MODULE=on GOPROXY=$(GOPROXY) go mod tidy
@echo "cd sdk && GO111MODULE=on GOPROXY=$(GOPROXY) go mod vendor"; cd sdk && GO111MODULE=on GOPROXY=$(GOPROXY) go mod vendor
@echo "cd pkg && GO111MODULE=on GOPROXY=$(GOPROXY) go mod tidy"; cd pkg && GO111MODULE=on GOPROXY=$(GOPROXY) go mod tidy
@echo "cd pkg && GO111MODULE=on GOPROXY=$(GOPROXY) go mod vendor"; cd pkg && GO111MODULE=on GOPROXY=$(GOPROXY) go mod vendor
@echo "cd examples && GO111MODULE=on GOPROXY=$(GOPROXY) go mod tidy"; cd examples && GO111MODULE=on GOPROXY=$(GOPROXY) go mod tidy
@echo "cd examples && GO111MODULE=on GOPROXY=$(GOPROXY) go mod vendor"; cd examples && GO111MODULE=on GOPROXY=$(GOPROXY) go mod vendor
@echo "cd tests && GO111MODULE=on GOPROXY=$(GOPROXY) go mod tidy"; cd tests && GO111MODULE=on GOPROXY=$(GOPROXY) go mod tidy
@echo "cd tests && GO111MODULE=on GOPROXY=$(GOPROXY) go mod vendor"; cd tests && GO111MODULE=on GOPROXY=$(GOPROXY) go mod vendor
endif
Make generate.sh reproducible
2018-07-12 22:29:35 +02:00
build-proto::
cd sdk/proto && ./generate.sh
Update schema-based docs generator (#4035) * Update properties.tmpl to render property comment as-is. WIP splitting out properties to lang-specific tables. * Generate the constructor dynamically from the resource per language. * Add doc functions in each language generator package for getting doc links for types..and later other functions too. * Render the constructor params in the Go code and inject into the template. * Generate nodejs types using the nodejs lang generator. * Add a templates bundler. Added a new Make target for autogenerating a static bundle for the resource docs generator. * Generate type links for all languages based on their schema type. Render the property type with a link if the underlying elements have a supporting type. Fix word-breaks for Python type names. * Various changes including the introduction of an interface type under the codegen package to help with generating some language-specific information for the resource docs generator. * Add a function to explicitly generate links for input types of nested types. Fix the resource doc link generator for Go. Don't replace the module name from the nodejs language type. * Fix bug with C# property type html encoding. * Fix some template formatting. Pass the state inputs for Python to generate the lookup function for it. * Do not generate the examples section if there are none. * Generating the property types per language. * Formatting. Rename function for readability. * Add comments. Update README. * Use relative URLs for doc links within the main site
2020-03-09 18:35:20 +01:00
.PHONY: generate
generate::
$(call STEP_MESSAGE)
echo "Generate static assets bundle for docs generator"
go generate ./pkg/codegen/docs/
Adopt new makefile system See https://github.com/pulumi/home/pull/56 for more details.
2017-11-12 01:20:56 +01:00
build::
duplicate version to ensure linking is properly handled
2020-03-19 20:49:34 +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::
duplicate version to ensure linking is properly handled
2020-03-19 20:49:34 +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
Added dist target for make, will help with Homebrew (#1731) * Added dist target for make, will help with Homebrew * Try to install go dependencies before building * Make sure dep ensure is called before trying to build SDKs * Removed dep ensure from dist initial step
2018-08-08 22:00:42 +02:00
dist::
duplicate version to ensure linking is properly handled
2020-03-19 20:49:34 +01:00
go install -ldflags "-X github.com/pulumi/pulumi/pkg/version.Version=${VERSION}" ${PROJECT}
Added dist target for make, will help with Homebrew (#1731) * Added dist target for make, will help with Homebrew * Try to install go dependencies before building * Make sure dep ensure is called before trying to build SDKs * Removed dep ensure from dist initial step
2018-08-08 22:00:42 +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
lint::
Merge branch 'master' of https://github.com/pulumi/pulumi into evan/gomod
2020-03-19 01:57:58 +01:00
for DIR in "examples" "pkg" "sdk" "tests" ; do \
Split linting per-directory. (#4106)
2020-03-18 21:51:25 +01:00
pushd $$DIR && golangci-lint run -c ../.golangci.yml --deadline 5m && popd ; \
done
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::
Make it simpler to run go tests consistently (#2479)
2019-02-26 22:39:33 +01:00
$(GO_TEST_FAST) ${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::
Run "integration" tests a package at a time
2019-08-06 20:50:17 +02:00
$(GO_TEST) ${PROJECT_PKGS}
$(GO_TEST) -v -p=1 ${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
Template tests will be part of the templates repo Fixes: #3744
2020-01-30 14:33:02 +01:00
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