yusheng-guo/kube-metrics-adapter
1
0
Fork 0
mirror of https://github.com/zalando-incubator/kube-metrics-adapter.git synced 2024-12-22 19:16:06 +00:00
Code Issues Packages Projects Releases Wiki Activity
kube-metrics-adapter/Makefile

74 lines
2.9 KiB
Makefile
Raw Normal View History

Adding boilerplate files Signed-off-by: Per Ploug <per.ploug@zalando.de>
2018-10-08 13:17:05 +02:00
.PHONY: clean test check build.local build.linux build.osx build.docker build.push
BINARY ?= kube-metrics-adapter
VERSION ?= $(shell git describe --tags --always --dirty)
Rename module path from mikkeloscar -> zalando-incubator Signed-off-by: Mikkel Oscar Lyderik Larsen <mikkel.larsen@zalando.de>
2018-10-14 11:37:58 +02:00
IMAGE ?= registry-write.opensource.zalan.do/teapot/$(BINARY)
Adding boilerplate files Signed-off-by: Per Ploug <per.ploug@zalando.de>
2018-10-08 13:17:05 +02:00
TAG ?= $(VERSION)
SOURCES = $(shell find . -name '*.go')
DOCKERFILE ?= Dockerfile
GOPKGS = $(shell go list ./...)
BUILD_FLAGS ?= -v
Fix openapi serving Signed-off-by: Mikkel Oscar Lyderik Larsen <mikkel.larsen@zalando.de>
2020-10-27 10:25:40 +01:00
OPENAPI ?= pkg/api/generated/openapi/zz_generated.openapi.go
Adding boilerplate files Signed-off-by: Per Ploug <per.ploug@zalando.de>
2018-10-08 13:17:05 +02:00
LDFLAGS ?= -X main.version=$(VERSION) -w -s
Create first version of ScalingSchedule CRDs Some cases and users actually know when their applications will have a high workload and, therefore, autoscaling support for time based scaling is a desired feature. This commit creates the first version of two CRDs called `ScalingSchedule` and `ClusterScalingSchedule`. The CRDs describe one or multiples schedules inside them. The schedules contains the information of when the time based scaling starts, if it happens once or multiple times, its duration and, a configurable value that later can be used by HPAs to scale applications. The only difference between the two CRDs is their scope. `ClusterScalingSchedule` aims to attend cluster wide schedules, to multiple applications, while `ScalingSchedule` has to be deployed with each application into the same namespace. This commit does not creates any metric, it's a noop change that creates just the CRD and import tools required to generate the CRD and others required code, as `deepCopy` functions and clients. Signed-off-by: Jonathan Juares Beber <jonathanbeber@gmail.com>
2021-03-19 19:33:38 +01:00
CRD_SOURCES = $(shell find pkg/apis/zalando.org -name '*.go')
CRD_TYPE_SOURCE = pkg/apis/zalando.org/v1/types.go
GENERATED_CRDS = docs/scaling_schedules_crd.yaml
GENERATED = pkg/apis/zalando.org/v1/zz_generated.deepcopy.go
Adding boilerplate files Signed-off-by: Per Ploug <per.ploug@zalando.de>
2018-10-08 13:17:05 +02:00
Fix openapi serving Signed-off-by: Mikkel Oscar Lyderik Larsen <mikkel.larsen@zalando.de>
2020-10-27 10:25:40 +01:00
Adding boilerplate files Signed-off-by: Per Ploug <per.ploug@zalando.de>
2018-10-08 13:17:05 +02:00
default: build.local
clean:
rm -rf build
Fix openapi serving Signed-off-by: Mikkel Oscar Lyderik Larsen <mikkel.larsen@zalando.de>
2020-10-27 10:25:40 +01:00
rm -rf $(OPENAPI)
Adding boilerplate files Signed-off-by: Per Ploug <per.ploug@zalando.de>
2018-10-08 13:17:05 +02:00
Create first version of ScalingSchedule CRDs Some cases and users actually know when their applications will have a high workload and, therefore, autoscaling support for time based scaling is a desired feature. This commit creates the first version of two CRDs called `ScalingSchedule` and `ClusterScalingSchedule`. The CRDs describe one or multiples schedules inside them. The schedules contains the information of when the time based scaling starts, if it happens once or multiple times, its duration and, a configurable value that later can be used by HPAs to scale applications. The only difference between the two CRDs is their scope. `ClusterScalingSchedule` aims to attend cluster wide schedules, to multiple applications, while `ScalingSchedule` has to be deployed with each application into the same namespace. This commit does not creates any metric, it's a noop change that creates just the CRD and import tools required to generate the CRD and others required code, as `deepCopy` functions and clients. Signed-off-by: Jonathan Juares Beber <jonathanbeber@gmail.com>
2021-03-19 19:33:38 +01:00
test: $(GENERATED)
Use Github actions instead of travis (#270) Signed-off-by: Mikkel Oscar Lyderik Larsen <mikkel.larsen@zalando.de>
2021-02-19 10:31:20 +01:00
go test -v -coverprofile=profile.cov $(GOPKGS)
Adding boilerplate files Signed-off-by: Per Ploug <per.ploug@zalando.de>
2018-10-08 13:17:05 +02:00
Create first version of ScalingSchedule CRDs Some cases and users actually know when their applications will have a high workload and, therefore, autoscaling support for time based scaling is a desired feature. This commit creates the first version of two CRDs called `ScalingSchedule` and `ClusterScalingSchedule`. The CRDs describe one or multiples schedules inside them. The schedules contains the information of when the time based scaling starts, if it happens once or multiple times, its duration and, a configurable value that later can be used by HPAs to scale applications. The only difference between the two CRDs is their scope. `ClusterScalingSchedule` aims to attend cluster wide schedules, to multiple applications, while `ScalingSchedule` has to be deployed with each application into the same namespace. This commit does not creates any metric, it's a noop change that creates just the CRD and import tools required to generate the CRD and others required code, as `deepCopy` functions and clients. Signed-off-by: Jonathan Juares Beber <jonathanbeber@gmail.com>
2021-03-19 19:33:38 +01:00
check: $(GENERATED)
Increase timeout for golangci-lint Signed-off-by: Mikkel Oscar Lyderik Larsen <mikkel.larsen@zalando.de>
2019-11-25 10:55:38 +01:00
go mod download
golangci-lint run --timeout=2m ./...
Adding boilerplate files Signed-off-by: Per Ploug <per.ploug@zalando.de>
2018-10-08 13:17:05 +02:00
Fix openapi serving Signed-off-by: Mikkel Oscar Lyderik Larsen <mikkel.larsen@zalando.de>
2020-10-27 10:25:40 +01:00
Update makefile dependencies Signed-off-by: Mikkel Oscar Lyderik Larsen <mikkel.larsen@zalando.de>
2021-04-13 11:17:46 +02:00
$(GENERATED): go.mod $(CRD_TYPE_SOURCE) $(OPENAPI)
Create first version of ScalingSchedule CRDs Some cases and users actually know when their applications will have a high workload and, therefore, autoscaling support for time based scaling is a desired feature. This commit creates the first version of two CRDs called `ScalingSchedule` and `ClusterScalingSchedule`. The CRDs describe one or multiples schedules inside them. The schedules contains the information of when the time based scaling starts, if it happens once or multiple times, its duration and, a configurable value that later can be used by HPAs to scale applications. The only difference between the two CRDs is their scope. `ClusterScalingSchedule` aims to attend cluster wide schedules, to multiple applications, while `ScalingSchedule` has to be deployed with each application into the same namespace. This commit does not creates any metric, it's a noop change that creates just the CRD and import tools required to generate the CRD and others required code, as `deepCopy` functions and clients. Signed-off-by: Jonathan Juares Beber <jonathanbeber@gmail.com>
2021-03-19 19:33:38 +01:00
./hack/update-codegen.sh
$(GENERATED_CRDS): $(GENERATED) $(CRD_SOURCES)
Update to Kubernetes v1.28 Signed-off-by: Mikkel Oscar Lyderik Larsen <mikkel.larsen@zalando.de>
2024-04-17 12:27:35 +02:00
go run sigs.k8s.io/controller-tools/cmd/controller-gen crd:crdVersions=v1 paths=./pkg/apis/... output:crd:dir=docs
Create first version of ScalingSchedule CRDs Some cases and users actually know when their applications will have a high workload and, therefore, autoscaling support for time based scaling is a desired feature. This commit creates the first version of two CRDs called `ScalingSchedule` and `ClusterScalingSchedule`. The CRDs describe one or multiples schedules inside them. The schedules contains the information of when the time based scaling starts, if it happens once or multiple times, its duration and, a configurable value that later can be used by HPAs to scale applications. The only difference between the two CRDs is their scope. `ClusterScalingSchedule` aims to attend cluster wide schedules, to multiple applications, while `ScalingSchedule` has to be deployed with each application into the same namespace. This commit does not creates any metric, it's a noop change that creates just the CRD and import tools required to generate the CRD and others required code, as `deepCopy` functions and clients. Signed-off-by: Jonathan Juares Beber <jonathanbeber@gmail.com>
2021-03-19 19:33:38 +01:00
mv docs/zalando.org_clusterscalingschedules.yaml docs/cluster_scaling_schedules_crd.yaml
mv docs/zalando.org_scalingschedules.yaml docs/scaling_schedules_crd.yaml
Fix openapi serving Signed-off-by: Mikkel Oscar Lyderik Larsen <mikkel.larsen@zalando.de>
2020-10-27 10:25:40 +01:00
$(OPENAPI): go.mod
go run k8s.io/kube-openapi/cmd/openapi-gen \
--go-header-file hack/boilerplate.go.txt \
--logtostderr \
-i k8s.io/metrics/pkg/apis/custom_metrics,k8s.io/metrics/pkg/apis/custom_metrics/v1beta1,k8s.io/metrics/pkg/apis/custom_metrics/v1beta2,k8s.io/metrics/pkg/apis/external_metrics,k8s.io/metrics/pkg/apis/external_metrics/v1beta1,k8s.io/metrics/pkg/apis/metrics,k8s.io/metrics/pkg/apis/metrics/v1beta1,k8s.io/apimachinery/pkg/apis/meta/v1,k8s.io/apimachinery/pkg/api/resource,k8s.io/apimachinery/pkg/version,k8s.io/api/core/v1 \
-p pkg/api/generated/openapi \
-o . \
-O zz_generated.openapi \
-r /dev/null
Update makefile dependencies Signed-off-by: Mikkel Oscar Lyderik Larsen <mikkel.larsen@zalando.de>
2021-04-13 11:17:46 +02:00
build.local: build/$(BINARY) $(GENERATED_CRDS)
Adding boilerplate files Signed-off-by: Per Ploug <per.ploug@zalando.de>
2018-10-08 13:17:05 +02:00
build.linux: build/linux/$(BINARY)
Build multi-arch image Signed-off-by: Mikkel Oscar Lyderik Larsen <mikkel.larsen@zalando.de>
2022-06-24 17:31:35 +02:00
build.linux.amd64: build/linux/amd64/$(BINARY)
build.linux.arm64: build/linux/arm64/$(BINARY)
Adding boilerplate files Signed-off-by: Per Ploug <per.ploug@zalando.de>
2018-10-08 13:17:05 +02:00
Update makefile dependencies Signed-off-by: Mikkel Oscar Lyderik Larsen <mikkel.larsen@zalando.de>
2021-04-13 11:17:46 +02:00
build/$(BINARY): go.mod $(SOURCES) $(GENERATED)
Adding boilerplate files Signed-off-by: Per Ploug <per.ploug@zalando.de>
2018-10-08 13:17:05 +02:00
CGO_ENABLED=0 go build -o build/$(BINARY) $(BUILD_FLAGS) -ldflags "$(LDFLAGS)" .
Update makefile dependencies Signed-off-by: Mikkel Oscar Lyderik Larsen <mikkel.larsen@zalando.de>
2021-04-13 11:17:46 +02:00
build/linux/$(BINARY): go.mod $(SOURCES) $(GENERATED)
Adding boilerplate files Signed-off-by: Per Ploug <per.ploug@zalando.de>
2018-10-08 13:17:05 +02:00
GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build $(BUILD_FLAGS) -o build/linux/$(BINARY) -ldflags "$(LDFLAGS)" .
Build multi-arch image Signed-off-by: Mikkel Oscar Lyderik Larsen <mikkel.larsen@zalando.de>
2022-06-24 17:31:35 +02:00
build/linux/amd64/$(BINARY): go.mod $(SOURCES)
GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build $(BUILD_FLAGS) -o build/linux/amd64/$(BINARY) -ldflags "$(LDFLAGS)" .
build/linux/arm64/$(BINARY): go.mod $(SOURCES)
GOOS=linux GOARCH=arm64 CGO_ENABLED=0 go build $(BUILD_FLAGS) -o build/linux/arm64/$(BINARY) -ldflags "$(LDFLAGS)" .
Adding boilerplate files Signed-off-by: Per Ploug <per.ploug@zalando.de>
2018-10-08 13:17:05 +02:00
build.docker: build.linux
Build multi-arch image Signed-off-by: Mikkel Oscar Lyderik Larsen <mikkel.larsen@zalando.de>
2022-06-24 17:31:35 +02:00
docker build --rm -t "$(IMAGE):$(TAG)" -f $(DOCKERFILE) --build-arg TARGETARCH= .
Adding boilerplate files Signed-off-by: Per Ploug <per.ploug@zalando.de>
2018-10-08 13:17:05 +02:00
build.push: build.docker
docker push "$(IMAGE):$(TAG)"
Reference in New Issue Copy Permalink