luxolus/open-vault
2
0
Fork 0
Code Issues 1 Pull requests Releases Activity
open-vault/vendor/github.com/joyent/triton-go/Makefile

48 lines
1.1 KiB
Makefile
Raw Normal View History

Update triton-go package (#8751)
2020-04-16 16:57:37 +00:00
#
# This Source Code Form is subject to the terms of the Mozilla Public
# License, v. 2.0. If a copy of the MPL was not distributed with this
# file, You can obtain one at http://mozilla.org/MPL/2.0/.
#
#
# Copyright 2019 Joyent, Inc.
#
Adding Manta Storage Backend (#3720) This PR adds a new Storage Backend for Triton's Object Storage - Manta ``` make testacc TEST=./physical/manta ==> Checking that code complies with gofmt requirements... ==> Checking that build is using go version >= 1.9.1... go generate VAULT_ACC=1 go test -tags='vault' ./physical/manta -v -timeout 45m === RUN TestMantaBackend --- PASS: TestMantaBackend (61.18s) PASS ok github.com/hashicorp/vault/physical/manta 61.210s ``` Manta behaves differently to how S3 works - it has no such concepts of Buckets - it is merely a filesystem style object store Therefore, we have chosen the approach of when writing a secret `foo` it will actually map (on disk) as foo/.vault_value The reason for this is because if we write the secret `foo/bar` and then try and Delete a key using the name `foo` then Manta will complain that the folder is not empty because `foo/bar` exists. Therefore, `foo/bar` is written as `foo/bar/.vault_value` The value of the key is *always* written to a directory tree of the name and put in a `.vault_value` file.
2018-02-12 23:22:41 +00:00
TEST?=$$(go list ./... |grep -Ev 'vendor|examples|testutils')
GOFMT_FILES?=$$(find . -name '*.go' |grep -v vendor)
Update triton-go package (#8751)
2020-04-16 16:57:37 +00:00
.PHONY: all
all:
Adding Manta Storage Backend (#3720) This PR adds a new Storage Backend for Triton's Object Storage - Manta ``` make testacc TEST=./physical/manta ==> Checking that code complies with gofmt requirements... ==> Checking that build is using go version >= 1.9.1... go generate VAULT_ACC=1 go test -tags='vault' ./physical/manta -v -timeout 45m === RUN TestMantaBackend --- PASS: TestMantaBackend (61.18s) PASS ok github.com/hashicorp/vault/physical/manta 61.210s ``` Manta behaves differently to how S3 works - it has no such concepts of Buckets - it is merely a filesystem style object store Therefore, we have chosen the approach of when writing a secret `foo` it will actually map (on disk) as foo/.vault_value The reason for this is because if we write the secret `foo/bar` and then try and Delete a key using the name `foo` then Manta will complain that the folder is not empty because `foo/bar` exists. Therefore, `foo/bar` is written as `foo/bar/.vault_value` The value of the key is *always* written to a directory tree of the name and put in a `.vault_value` file.
2018-02-12 23:22:41 +00:00
Update triton-go package (#8751)
2020-04-16 16:57:37 +00:00
.PHONY: tools
tools: ## Download and install all dev/code tools
Adding Manta Storage Backend (#3720) This PR adds a new Storage Backend for Triton's Object Storage - Manta ``` make testacc TEST=./physical/manta ==> Checking that code complies with gofmt requirements... ==> Checking that build is using go version >= 1.9.1... go generate VAULT_ACC=1 go test -tags='vault' ./physical/manta -v -timeout 45m === RUN TestMantaBackend --- PASS: TestMantaBackend (61.18s) PASS ok github.com/hashicorp/vault/physical/manta 61.210s ``` Manta behaves differently to how S3 works - it has no such concepts of Buckets - it is merely a filesystem style object store Therefore, we have chosen the approach of when writing a secret `foo` it will actually map (on disk) as foo/.vault_value The reason for this is because if we write the secret `foo/bar` and then try and Delete a key using the name `foo` then Manta will complain that the folder is not empty because `foo/bar` exists. Therefore, `foo/bar` is written as `foo/bar/.vault_value` The value of the key is *always* written to a directory tree of the name and put in a `.vault_value` file.
2018-02-12 23:22:41 +00:00
@echo "==> Installing dev tools"
go get -u github.com/golang/dep/cmd/dep
Bump Deps (#4868) * bump deps * revert script changes * adding govendor miss
2018-07-06 16:09:34 +00:00
Update triton-go package (#8751)
2020-04-16 16:57:37 +00:00
.PHONY: build
build:
Bump Deps (#4868) * bump deps * revert script changes * adding govendor miss
2018-07-06 16:09:34 +00:00
@govvv build
Update triton-go package (#8751)
2020-04-16 16:57:37 +00:00
.PHONY: install
install:
Bump Deps (#4868) * bump deps * revert script changes * adding govendor miss
2018-07-06 16:09:34 +00:00
@govvv install
Adding Manta Storage Backend (#3720) This PR adds a new Storage Backend for Triton's Object Storage - Manta ``` make testacc TEST=./physical/manta ==> Checking that code complies with gofmt requirements... ==> Checking that build is using go version >= 1.9.1... go generate VAULT_ACC=1 go test -tags='vault' ./physical/manta -v -timeout 45m === RUN TestMantaBackend --- PASS: TestMantaBackend (61.18s) PASS ok github.com/hashicorp/vault/physical/manta 61.210s ``` Manta behaves differently to how S3 works - it has no such concepts of Buckets - it is merely a filesystem style object store Therefore, we have chosen the approach of when writing a secret `foo` it will actually map (on disk) as foo/.vault_value The reason for this is because if we write the secret `foo/bar` and then try and Delete a key using the name `foo` then Manta will complain that the folder is not empty because `foo/bar` exists. Therefore, `foo/bar` is written as `foo/bar/.vault_value` The value of the key is *always* written to a directory tree of the name and put in a `.vault_value` file.
2018-02-12 23:22:41 +00:00
Update triton-go package (#8751)
2020-04-16 16:57:37 +00:00
.PHONY: test
test: ## Run unit tests
Adding Manta Storage Backend (#3720) This PR adds a new Storage Backend for Triton's Object Storage - Manta ``` make testacc TEST=./physical/manta ==> Checking that code complies with gofmt requirements... ==> Checking that build is using go version >= 1.9.1... go generate VAULT_ACC=1 go test -tags='vault' ./physical/manta -v -timeout 45m === RUN TestMantaBackend --- PASS: TestMantaBackend (61.18s) PASS ok github.com/hashicorp/vault/physical/manta 61.210s ``` Manta behaves differently to how S3 works - it has no such concepts of Buckets - it is merely a filesystem style object store Therefore, we have chosen the approach of when writing a secret `foo` it will actually map (on disk) as foo/.vault_value The reason for this is because if we write the secret `foo/bar` and then try and Delete a key using the name `foo` then Manta will complain that the folder is not empty because `foo/bar` exists. Therefore, `foo/bar` is written as `foo/bar/.vault_value` The value of the key is *always* written to a directory tree of the name and put in a `.vault_value` file.
2018-02-12 23:22:41 +00:00
@echo "==> Running unit test with coverage"
@./scripts/go-test-with-coverage.sh
Update triton-go package (#8751)
2020-04-16 16:57:37 +00:00
.PHONY: testacc
testacc: ## Run acceptance tests
Adding Manta Storage Backend (#3720) This PR adds a new Storage Backend for Triton's Object Storage - Manta ``` make testacc TEST=./physical/manta ==> Checking that code complies with gofmt requirements... ==> Checking that build is using go version >= 1.9.1... go generate VAULT_ACC=1 go test -tags='vault' ./physical/manta -v -timeout 45m === RUN TestMantaBackend --- PASS: TestMantaBackend (61.18s) PASS ok github.com/hashicorp/vault/physical/manta 61.210s ``` Manta behaves differently to how S3 works - it has no such concepts of Buckets - it is merely a filesystem style object store Therefore, we have chosen the approach of when writing a secret `foo` it will actually map (on disk) as foo/.vault_value The reason for this is because if we write the secret `foo/bar` and then try and Delete a key using the name `foo` then Manta will complain that the folder is not empty because `foo/bar` exists. Therefore, `foo/bar` is written as `foo/bar/.vault_value` The value of the key is *always* written to a directory tree of the name and put in a `.vault_value` file.
2018-02-12 23:22:41 +00:00
@echo "==> Running acceptance tests"
TRITON_TEST=1 go test $(TEST) -v $(TESTARGS) -run -timeout 120m
Update triton-go package (#8751)
2020-04-16 16:57:37 +00:00
.PHONY: check
check:
scripts/gofmt-check.sh
Adding Manta Storage Backend (#3720) This PR adds a new Storage Backend for Triton's Object Storage - Manta ``` make testacc TEST=./physical/manta ==> Checking that code complies with gofmt requirements... ==> Checking that build is using go version >= 1.9.1... go generate VAULT_ACC=1 go test -tags='vault' ./physical/manta -v -timeout 45m === RUN TestMantaBackend --- PASS: TestMantaBackend (61.18s) PASS ok github.com/hashicorp/vault/physical/manta 61.210s ``` Manta behaves differently to how S3 works - it has no such concepts of Buckets - it is merely a filesystem style object store Therefore, we have chosen the approach of when writing a secret `foo` it will actually map (on disk) as foo/.vault_value The reason for this is because if we write the secret `foo/bar` and then try and Delete a key using the name `foo` then Manta will complain that the folder is not empty because `foo/bar` exists. Therefore, `foo/bar` is written as `foo/bar/.vault_value` The value of the key is *always* written to a directory tree of the name and put in a `.vault_value` file.
2018-02-12 23:22:41 +00:00
.PHONY: help
Update triton-go package (#8751)
2020-04-16 16:57:37 +00:00
help: ## Display this help message
Adding Manta Storage Backend (#3720) This PR adds a new Storage Backend for Triton's Object Storage - Manta ``` make testacc TEST=./physical/manta ==> Checking that code complies with gofmt requirements... ==> Checking that build is using go version >= 1.9.1... go generate VAULT_ACC=1 go test -tags='vault' ./physical/manta -v -timeout 45m === RUN TestMantaBackend --- PASS: TestMantaBackend (61.18s) PASS ok github.com/hashicorp/vault/physical/manta 61.210s ``` Manta behaves differently to how S3 works - it has no such concepts of Buckets - it is merely a filesystem style object store Therefore, we have chosen the approach of when writing a secret `foo` it will actually map (on disk) as foo/.vault_value The reason for this is because if we write the secret `foo/bar` and then try and Delete a key using the name `foo` then Manta will complain that the folder is not empty because `foo/bar` exists. Therefore, `foo/bar` is written as `foo/bar/.vault_value` The value of the key is *always* written to a directory tree of the name and put in a `.vault_value` file.
2018-02-12 23:22:41 +00:00
@echo "GNU make(1) targets:"
@grep -E '^[a-zA-Z_.-]+:.*?## .*$$' $(MAKEFILE_LIST) | sort | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-15s\033[0m %s\n", $$1, $$2}'
Reference in a new issue Copy permalink