2021-05-01 08:10:57 +02:00
i f d e f D O C K E R _ U S E R
NAME ?= ${ DOCKER_USER } /actions-runner-controller
e l s e
NAME ?= summerwind/actions-runner-controller
e n d i f
DOCKER_USER ?= $( shell echo ${ NAME } | cut -d / -f1)
2020-02-02 21:38:11 +09:00
VERSION ?= latest
2021-05-03 13:03:17 +09:00
RUNNER_NAME ?= ${ DOCKER_USER } /actions-runner
RUNNER_TAG ?= ${ VERSION }
2021-05-01 08:10:57 +02:00
TEST_REPO ?= ${ DOCKER_USER } /actions-runner-controller
2021-05-11 06:30:57 +00:00
TEST_ORG ?=
TEST_ORG_REPO ?=
2021-05-02 16:31:07 +09:00
SYNC_PERIOD ?= 5m
2021-06-22 17:10:09 +09:00
USE_RUNNERSET ?=
KUBECONTEXT ?= kind-acceptance
CLUSTER ?= acceptance
CERT_MANAGER_VERSION ?= v1.1.1
2021-05-01 08:10:57 +02:00
2020-10-15 02:39:46 +03:00
# From https://github.com/VictoriaMetrics/operator/pull/44
YAML_DROP = $( YQ) delete --inplace
2021-06-22 17:10:09 +09:00
# If you encounter errors like the below, you are very likely to update this to follow e.g. CRD version change:
# CustomResourceDefinition.apiextensions.k8s.io "runners.actions.summerwind.dev" is invalid: spec.preserveUnknownFields: Invalid value: true: must be false in order to use defaults in the schema
YAML_DROP_PREFIX = spec.versions[ 0] .schema.openAPIV3Schema.properties.spec.properties
2020-01-28 15:03:23 +09:00
# Produce CRDs that work back to Kubernetes 1.11 (no version conversion)
2021-06-22 17:10:09 +09:00
CRD_OPTIONS ?= "crd:trivialVersions=true,generateEmbeddedObjectMeta=true"
2020-01-28 15:03:23 +09:00
# Get the currently used golang install path (in GOPATH/bin, unless GOBIN is set)
i f e q ( , $( shell go env GOBIN ) )
GOBIN = $( shell go env GOPATH) /bin
e l s e
GOBIN = $( shell go env GOBIN)
e n d i f
2021-03-31 09:23:16 +09:00
TEST_ASSETS = $( PWD) /test-assets
2020-10-05 11:26:46 +11:00
# default list of platforms for which multiarch image is built
i f e q ( $ { P L A T F O R M S } , )
export PLATFORMS = "linux/amd64,linux/arm64"
e n d i f
# if IMG_RESULT is unspecified, by default the image will be pushed to registry
i f e q ( $ { I M G _ R E S U L T } , l o a d )
export PUSH_ARG = "--load"
2021-05-01 08:10:57 +02:00
# if load is specified, image will be built only for the build machine architecture.
export PLATFORMS = "local"
2020-10-05 11:26:46 +11:00
e l s e i f e q ( $ { I M G _ R E S U L T } , c a c h e )
# if cache is specified, image will only be available in the build cache, it won't be pushed or loaded
# therefore no PUSH_ARG will be specified
e l s e
export PUSH_ARG = "--push"
e n d i f
2020-01-28 15:03:23 +09:00
all : manager
2021-06-27 16:28:07 +09:00
GO_TEST_ARGS ?= -short
2020-01-28 15:03:23 +09:00
# Run tests
test : generate fmt vet manifests
2021-06-27 16:28:07 +09:00
go test $( GO_TEST_ARGS) ./... -coverprofile cover.out
2020-01-28 15:03:23 +09:00
2021-03-31 09:23:16 +09:00
test-with-deps : kube -apiserver etcd kubectl
# See https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/envtest#pkg-constants
TEST_ASSET_KUBE_APISERVER = $( KUBE_APISERVER_BIN) \
TEST_ASSET_ETCD = $( ETCD_BIN) \
TEST_ASSET_KUBECTL = $( KUBECTL_BIN) \
make test
2020-01-28 15:03:23 +09:00
# Build manager binary
manager : generate fmt vet
go build -o bin/manager main.go
# Run against the configured Kubernetes cluster in ~/.kube/config
run : generate fmt vet manifests
go run ./main.go
# Install CRDs into a cluster
install : manifests
kustomize build config/crd | kubectl apply -f -
# Uninstall CRDs from a cluster
uninstall : manifests
kustomize build config/crd | kubectl delete -f -
# Deploy controller in the configured Kubernetes cluster in ~/.kube/config
deploy : manifests
2020-02-02 21:38:11 +09:00
cd config/manager && kustomize edit set image controller = ${ NAME } :${ VERSION }
2020-01-28 15:03:23 +09:00
kustomize build config/default | kubectl apply -f -
# Generate manifests e.g. CRD, RBAC etc.
2020-11-14 20:31:21 +09:00
manifests : manifests -118 fix 118 chart -crds
2020-10-15 02:39:46 +03:00
manifests-118 : controller -gen
2020-01-28 15:03:23 +09:00
$( CONTROLLER_GEN) $( CRD_OPTIONS) rbac:roleName= manager-role webhook paths = "./..." output:crd:artifacts:config= config/crd/bases
2020-11-14 20:31:21 +09:00
chart-crds :
cp config/crd/bases/*.yaml charts/actions-runner-controller/crds/
2020-01-28 15:03:23 +09:00
# Run go fmt against code
fmt :
go fmt ./...
# Run go vet against code
vet :
go vet ./...
2020-10-15 02:39:46 +03:00
# workaround for CRD issue with k8s 1.18 & controller-gen
# ref: https://github.com/kubernetes/kubernetes/issues/91395
fix118 : yq
2020-10-20 02:48:28 +03:00
$( YAML_DROP) config/crd/bases/actions.summerwind.dev_runnerreplicasets.yaml $( YAML_DROP_PREFIX) .template.properties.spec.properties.containers.items.properties
$( YAML_DROP) config/crd/bases/actions.summerwind.dev_runnerreplicasets.yaml $( YAML_DROP_PREFIX) .template.properties.spec.properties.initContainers.items.properties
$( YAML_DROP) config/crd/bases/actions.summerwind.dev_runnerreplicasets.yaml $( YAML_DROP_PREFIX) .template.properties.spec.properties.sidecarContainers.items.properties
$( YAML_DROP) config/crd/bases/actions.summerwind.dev_runnerreplicasets.yaml $( YAML_DROP_PREFIX) .template.properties.spec.properties.ephemeralContainers.items.properties
$( YAML_DROP) config/crd/bases/actions.summerwind.dev_runnerdeployments.yaml $( YAML_DROP_PREFIX) .template.properties.spec.properties.containers.items.properties
$( YAML_DROP) config/crd/bases/actions.summerwind.dev_runnerdeployments.yaml $( YAML_DROP_PREFIX) .template.properties.spec.properties.initContainers.items.properties
$( YAML_DROP) config/crd/bases/actions.summerwind.dev_runnerdeployments.yaml $( YAML_DROP_PREFIX) .template.properties.spec.properties.sidecarContainers.items.properties
$( YAML_DROP) config/crd/bases/actions.summerwind.dev_runnerdeployments.yaml $( YAML_DROP_PREFIX) .template.properties.spec.properties.ephemeralContainers.items.properties
$( YAML_DROP) config/crd/bases/actions.summerwind.dev_runners.yaml $( YAML_DROP_PREFIX) .containers.items.properties
$( YAML_DROP) config/crd/bases/actions.summerwind.dev_runners.yaml $( YAML_DROP_PREFIX) .initContainers.items.properties
$( YAML_DROP) config/crd/bases/actions.summerwind.dev_runners.yaml $( YAML_DROP_PREFIX) .sidecarContainers.items.properties
$( YAML_DROP) config/crd/bases/actions.summerwind.dev_runners.yaml $( YAML_DROP_PREFIX) .ephemeralContainers.items.properties
2020-10-15 02:39:46 +03:00
2020-01-28 15:03:23 +09:00
# Generate code
2020-10-20 02:48:28 +03:00
generate : controller -gen
2020-01-28 15:03:23 +09:00
$( CONTROLLER_GEN) object:headerFile= ./hack/boilerplate.go.txt paths = "./..."
# Build the docker image
feat: Support for scaling from/to zero (#465)
This is an attempt to support scaling from/to zero.
The basic idea is that we create a one-off "registration-only" runner pod on RunnerReplicaSet being scaled to zero, so that there is one "offline" runner, which enables GitHub Actions to queue jobs instead of discarding those.
GitHub Actions seems to immediately throw away the new job when there are no runners at all. Generally, having runners of any status, `busy`, `idle`, or `offline` would prevent GitHub actions from failing jobs. But retaining `busy` or `idle` runners means that we need to keep runner pods running, which conflicts with our desired to scale to/from zero, hence we retain `offline` runners.
In this change, I enhanced the runnerreplicaset controller to create a registration-only runner on very beginning of its reconciliation logic, only when a runnerreplicaset is scaled to zero. The runner controller creates the registration-only runner pod, waits for it to become "offline", and then removes the runner pod. The runner on GitHub stays `offline`, until the runner resource on K8s is deleted. As we remove the registration-only runner pod as soon as it registers, this doesn't block cluster-autoscaler.
Related to #447
2021-05-02 16:11:36 +09:00
docker-build :
2020-02-02 21:38:11 +09:00
docker build . -t ${ NAME } :${ VERSION }
2021-05-03 13:03:17 +09:00
docker build runner -t ${ RUNNER_NAME } :${ RUNNER_TAG } --build-arg TARGETPLATFORM = $( shell arch)
2020-01-28 15:03:23 +09:00
2020-10-05 11:26:46 +11:00
docker-buildx :
export DOCKER_CLI_EXPERIMENTAL = enabled
@if ! docker buildx ls | grep -q container-builder; then \
docker buildx create --platform ${ PLATFORMS } --name container-builder --use; \
fi
docker buildx build --platform ${ PLATFORMS } \
--build-arg RUNNER_VERSION = ${ RUNNER_VERSION } \
--build-arg DOCKER_VERSION = ${ DOCKER_VERSION } \
-t " ${ NAME } : ${ VERSION } " \
-f Dockerfile \
. ${ PUSH_ARG }
2021-05-01 08:10:57 +02:00
# Push the docker image
docker-push :
docker push ${ NAME } :${ VERSION }
2021-05-03 13:03:17 +09:00
docker push ${ RUNNER_NAME } :${ RUNNER_TAG }
2021-05-01 08:10:57 +02:00
2020-02-03 10:28:50 +09:00
# Generate the release manifest file
2020-02-03 12:06:34 +09:00
release : manifests
2020-02-03 16:55:38 +09:00
cd config/manager && kustomize edit set image controller = ${ NAME } :${ VERSION }
2020-02-03 10:28:50 +09:00
mkdir -p release
kustomize build config/default > release/actions-runner-controller.yaml
2020-12-06 11:53:38 +09:00
.PHONY : release /clean
release/clean :
rm -rf release
2020-11-14 20:07:14 +09:00
.PHONY : acceptance
2021-05-02 16:31:07 +09:00
acceptance : release /clean acceptance /pull docker -build release
ACCEPTANCE_TEST_SECRET_TYPE = token make acceptance/run
ACCEPTANCE_TEST_SECRET_TYPE = app make acceptance/run
ACCEPTANCE_TEST_DEPLOYMENT_TOOL = helm ACCEPTANCE_TEST_SECRET_TYPE = token make acceptance/run
ACCEPTANCE_TEST_DEPLOYMENT_TOOL = helm ACCEPTANCE_TEST_SECRET_TYPE = app make acceptance/run
acceptance/run : acceptance /kind acceptance /load acceptance /setup acceptance /deploy acceptance /tests acceptance /teardown
2020-11-14 20:07:14 +09:00
2020-12-08 17:56:06 +09:00
acceptance/kind :
2021-06-22 17:10:09 +09:00
kind create cluster --name ${ CLUSTER } --config acceptance/kind.yaml
2021-05-02 16:31:07 +09:00
# Set TMPDIR to somewhere under $HOME when you use docker installed with Ubuntu snap
# Otherwise `load docker-image` fail while running `docker save`.
# See https://kind.sigs.k8s.io/docs/user/known-issues/#docker-installed-with-snap
acceptance/load :
2021-06-22 17:10:09 +09:00
kind load docker-image ${ NAME } :${ VERSION } --name ${ CLUSTER }
kind load docker-image quay.io/brancz/kube-rbac-proxy:v0.10.0 --name ${ CLUSTER }
kind load docker-image ${ RUNNER_NAME } :${ RUNNER_TAG } --name ${ CLUSTER }
kind load docker-image docker:dind --name ${ CLUSTER }
kind load docker-image quay.io/jetstack/cert-manager-controller:$( CERT_MANAGER_VERSION) --name ${ CLUSTER }
kind load docker-image quay.io/jetstack/cert-manager-cainjector:$( CERT_MANAGER_VERSION) --name ${ CLUSTER }
kind load docker-image quay.io/jetstack/cert-manager-webhook:$( CERT_MANAGER_VERSION) --name ${ CLUSTER }
kubectl cluster-info --context ${ KUBECONTEXT }
2020-12-08 17:56:06 +09:00
2021-05-01 08:10:57 +02:00
# Pull the docker images for acceptance
2021-05-02 16:31:07 +09:00
acceptance/pull :
2021-06-08 11:16:30 -06:00
docker pull quay.io/brancz/kube-rbac-proxy:v0.10.0
2021-05-02 16:31:07 +09:00
docker pull docker:dind
2021-06-22 17:10:09 +09:00
docker pull quay.io/jetstack/cert-manager-controller:$( CERT_MANAGER_VERSION)
docker pull quay.io/jetstack/cert-manager-cainjector:$( CERT_MANAGER_VERSION)
docker pull quay.io/jetstack/cert-manager-webhook:$( CERT_MANAGER_VERSION)
2021-04-18 02:44:59 +02:00
2020-12-08 17:56:06 +09:00
acceptance/setup :
2021-06-22 17:10:09 +09:00
kubectl apply --validate= false -f https://github.com/jetstack/cert-manager/releases/download/$( CERT_MANAGER_VERSION) /cert-manager.yaml #kubectl create namespace actions-runner-system
feat: Support for scaling from/to zero (#465)
This is an attempt to support scaling from/to zero.
The basic idea is that we create a one-off "registration-only" runner pod on RunnerReplicaSet being scaled to zero, so that there is one "offline" runner, which enables GitHub Actions to queue jobs instead of discarding those.
GitHub Actions seems to immediately throw away the new job when there are no runners at all. Generally, having runners of any status, `busy`, `idle`, or `offline` would prevent GitHub actions from failing jobs. But retaining `busy` or `idle` runners means that we need to keep runner pods running, which conflicts with our desired to scale to/from zero, hence we retain `offline` runners.
In this change, I enhanced the runnerreplicaset controller to create a registration-only runner on very beginning of its reconciliation logic, only when a runnerreplicaset is scaled to zero. The runner controller creates the registration-only runner pod, waits for it to become "offline", and then removes the runner pod. The runner on GitHub stays `offline`, until the runner resource on K8s is deleted. As we remove the registration-only runner pod as soon as it registers, this doesn't block cluster-autoscaler.
Related to #447
2021-05-02 16:11:36 +09:00
kubectl -n cert-manager wait deploy/cert-manager-cainjector --for condition = available --timeout 90s
2020-11-14 20:07:14 +09:00
kubectl -n cert-manager wait deploy/cert-manager-webhook --for condition = available --timeout 60s
kubectl -n cert-manager wait deploy/cert-manager --for condition = available --timeout 60s
2020-12-08 17:56:06 +09:00
kubectl create namespace actions-runner-system || true
2020-11-14 20:07:14 +09:00
# Adhocly wait for some time until cert-manager's admission webhook gets ready
sleep 5
acceptance/teardown :
2021-06-22 17:10:09 +09:00
kind delete cluster --name ${ CLUSTER }
2020-11-14 20:07:14 +09:00
2021-05-02 16:31:07 +09:00
acceptance/deploy :
2021-05-11 06:30:57 +00:00
NAME = ${ NAME } DOCKER_USER = ${ DOCKER_USER } VERSION = ${ VERSION } RUNNER_NAME = ${ RUNNER_NAME } RUNNER_TAG = ${ RUNNER_TAG } TEST_REPO = ${ TEST_REPO } \
2021-05-11 13:30:34 +02:00
TEST_ORG = ${ TEST_ORG } TEST_ORG_REPO = ${ TEST_ORG_REPO } SYNC_PERIOD = ${ SYNC_PERIOD } \
2021-06-22 17:10:09 +09:00
USE_RUNNERSET = ${ USE_RUNNERSET } \
2021-05-11 06:30:57 +00:00
acceptance/deploy.sh
2021-05-02 16:31:07 +09:00
acceptance/tests :
2020-11-14 20:07:14 +09:00
acceptance/checks.sh
2020-02-03 10:28:50 +09:00
# Upload release file to GitHub.
github-release : release
ghr ${ VERSION } release/
2021-06-22 17:10:09 +09:00
# Find or download controller-gen
#
# Note that controller-gen newer than 0.4.1 is needed for https://github.com/kubernetes-sigs/controller-tools/issues/444#issuecomment-680168439
# Otherwise we get errors like the below:
# Error: failed to install CRD crds/actions.summerwind.dev_runnersets.yaml: CustomResourceDefinition.apiextensions.k8s.io "runnersets.actions.summerwind.dev" is invalid: [spec.validation.openAPIV3Schema.properties[spec].properties[template].properties[spec].properties[containers].items.properties[ports].items.properties[protocol].default: Required value: this property is in x-kubernetes-list-map-keys, so it must have a default or be a required property, spec.validation.openAPIV3Schema.properties[spec].properties[template].properties[spec].properties[initContainers].items.properties[ports].items.properties[protocol].default: Required value: this property is in x-kubernetes-list-map-keys, so it must have a default or be a required property]
#
# Note that controller-gen newer than 0.6.0 is needed due to https://github.com/kubernetes-sigs/controller-tools/issues/448
# Otherwise ObjectMeta embedded in Spec results in empty on the storage.
2020-01-28 15:03:23 +09:00
controller-gen :
i f e q ( , $( shell which controller -gen ) )
2020-10-20 02:48:28 +03:00
i f e q ( , $( wildcard $ ( GOBIN ) /controller -gen ) )
2020-01-28 15:03:23 +09:00
@{ \
set -e ; \
CONTROLLER_GEN_TMP_DIR = $$ ( mktemp -d) ; \
cd $$ CONTROLLER_GEN_TMP_DIR ; \
go mod init tmp ; \
2021-06-22 17:10:09 +09:00
go get sigs.k8s.io/controller-tools/cmd/controller-gen@v0.6.0 ; \
2020-01-28 15:03:23 +09:00
rm -rf $$ CONTROLLER_GEN_TMP_DIR ; \
}
2020-10-20 02:48:28 +03:00
e n d i f
2020-01-28 15:03:23 +09:00
CONTROLLER_GEN = $( GOBIN) /controller-gen
e l s e
CONTROLLER_GEN = $( shell which controller-gen)
e n d i f
2020-10-15 02:39:46 +03:00
# find or download yq
# download yq if necessary
2020-10-20 02:48:28 +03:00
# Use always go-version to get consistent line wraps etc.
2020-10-15 02:39:46 +03:00
yq :
2020-10-20 02:48:28 +03:00
i f e q ( , $( wildcard $ ( GOBIN ) /yq ) )
2020-10-15 02:39:46 +03:00
echo "Downloading yq"
@{ \
set -e ; \
YQ_TMP_DIR = $$ ( mktemp -d) ; \
cd $$ YQ_TMP_DIR ; \
go mod init tmp ; \
2020-10-20 02:48:28 +03:00
go get github.com/mikefarah/yq/v3@3.4.0 ; \
2020-10-15 02:39:46 +03:00
rm -rf $$ YQ_TMP_DIR ; \
}
e n d i f
2020-10-20 02:48:28 +03:00
YQ = $( GOBIN) /yq
2021-03-31 09:23:16 +09:00
OS_NAME := $( shell uname -s | tr A-Z a-z)
# find or download etcd
etcd :
feat: Support for scaling from/to zero (#465)
This is an attempt to support scaling from/to zero.
The basic idea is that we create a one-off "registration-only" runner pod on RunnerReplicaSet being scaled to zero, so that there is one "offline" runner, which enables GitHub Actions to queue jobs instead of discarding those.
GitHub Actions seems to immediately throw away the new job when there are no runners at all. Generally, having runners of any status, `busy`, `idle`, or `offline` would prevent GitHub actions from failing jobs. But retaining `busy` or `idle` runners means that we need to keep runner pods running, which conflicts with our desired to scale to/from zero, hence we retain `offline` runners.
In this change, I enhanced the runnerreplicaset controller to create a registration-only runner on very beginning of its reconciliation logic, only when a runnerreplicaset is scaled to zero. The runner controller creates the registration-only runner pod, waits for it to become "offline", and then removes the runner pod. The runner on GitHub stays `offline`, until the runner resource on K8s is deleted. As we remove the registration-only runner pod as soon as it registers, this doesn't block cluster-autoscaler.
Related to #447
2021-05-02 16:11:36 +09:00
i f e q ( , $( shell which etcd ) )
2021-03-31 09:23:16 +09:00
i f e q ( , $( wildcard $ ( TEST_ASSETS ) /etcd ) )
@{ \
set -xe ; \
INSTALL_TMP_DIR = $$ ( mktemp -d) ; \
cd $$ INSTALL_TMP_DIR ; \
wget https://github.com/kubernetes-sigs/kubebuilder/releases/download/v2.3.2/kubebuilder_2.3.2_$( OS_NAME) _amd64.tar.gz ; \
mkdir -p $( TEST_ASSETS) ; \
tar zxvf kubebuilder_2.3.2_$( OS_NAME) _amd64.tar.gz ; \
mv kubebuilder_2.3.2_$( OS_NAME) _amd64/bin/etcd $( TEST_ASSETS) /etcd ; \
mv kubebuilder_2.3.2_$( OS_NAME) _amd64/bin/kube-apiserver $( TEST_ASSETS) /kube-apiserver ; \
mv kubebuilder_2.3.2_$( OS_NAME) _amd64/bin/kubectl $( TEST_ASSETS) /kubectl ; \
rm -rf $$ INSTALL_TMP_DIR ; \
}
ETCD_BIN = $( TEST_ASSETS) /etcd
e l s e
ETCD_BIN = $( TEST_ASSETS) /etcd
e n d i f
feat: Support for scaling from/to zero (#465)
This is an attempt to support scaling from/to zero.
The basic idea is that we create a one-off "registration-only" runner pod on RunnerReplicaSet being scaled to zero, so that there is one "offline" runner, which enables GitHub Actions to queue jobs instead of discarding those.
GitHub Actions seems to immediately throw away the new job when there are no runners at all. Generally, having runners of any status, `busy`, `idle`, or `offline` would prevent GitHub actions from failing jobs. But retaining `busy` or `idle` runners means that we need to keep runner pods running, which conflicts with our desired to scale to/from zero, hence we retain `offline` runners.
In this change, I enhanced the runnerreplicaset controller to create a registration-only runner on very beginning of its reconciliation logic, only when a runnerreplicaset is scaled to zero. The runner controller creates the registration-only runner pod, waits for it to become "offline", and then removes the runner pod. The runner on GitHub stays `offline`, until the runner resource on K8s is deleted. As we remove the registration-only runner pod as soon as it registers, this doesn't block cluster-autoscaler.
Related to #447
2021-05-02 16:11:36 +09:00
e l s e
ETCD_BIN = $( shell which etcd)
e n d i f
2021-03-31 09:23:16 +09:00
# find or download kube-apiserver
kube-apiserver :
feat: Support for scaling from/to zero (#465)
This is an attempt to support scaling from/to zero.
The basic idea is that we create a one-off "registration-only" runner pod on RunnerReplicaSet being scaled to zero, so that there is one "offline" runner, which enables GitHub Actions to queue jobs instead of discarding those.
GitHub Actions seems to immediately throw away the new job when there are no runners at all. Generally, having runners of any status, `busy`, `idle`, or `offline` would prevent GitHub actions from failing jobs. But retaining `busy` or `idle` runners means that we need to keep runner pods running, which conflicts with our desired to scale to/from zero, hence we retain `offline` runners.
In this change, I enhanced the runnerreplicaset controller to create a registration-only runner on very beginning of its reconciliation logic, only when a runnerreplicaset is scaled to zero. The runner controller creates the registration-only runner pod, waits for it to become "offline", and then removes the runner pod. The runner on GitHub stays `offline`, until the runner resource on K8s is deleted. As we remove the registration-only runner pod as soon as it registers, this doesn't block cluster-autoscaler.
Related to #447
2021-05-02 16:11:36 +09:00
i f e q ( , $( shell which kube -apiserver ) )
2021-03-31 09:23:16 +09:00
i f e q ( , $( wildcard $ ( TEST_ASSETS ) /kube -apiserver ) )
@{ \
set -xe ; \
INSTALL_TMP_DIR = $$ ( mktemp -d) ; \
cd $$ INSTALL_TMP_DIR ; \
wget https://github.com/kubernetes-sigs/kubebuilder/releases/download/v2.3.2/kubebuilder_2.3.2_$( OS_NAME) _amd64.tar.gz ; \
mkdir -p $( TEST_ASSETS) ; \
tar zxvf kubebuilder_2.3.2_$( OS_NAME) _amd64.tar.gz ; \
mv kubebuilder_2.3.2_$( OS_NAME) _amd64/bin/etcd $( TEST_ASSETS) /etcd ; \
mv kubebuilder_2.3.2_$( OS_NAME) _amd64/bin/kube-apiserver $( TEST_ASSETS) /kube-apiserver ; \
mv kubebuilder_2.3.2_$( OS_NAME) _amd64/bin/kubectl $( TEST_ASSETS) /kubectl ; \
rm -rf $$ INSTALL_TMP_DIR ; \
}
KUBE_APISERVER_BIN = $( TEST_ASSETS) /kube-apiserver
e l s e
KUBE_APISERVER_BIN = $( TEST_ASSETS) /kube-apiserver
e n d i f
feat: Support for scaling from/to zero (#465)
This is an attempt to support scaling from/to zero.
The basic idea is that we create a one-off "registration-only" runner pod on RunnerReplicaSet being scaled to zero, so that there is one "offline" runner, which enables GitHub Actions to queue jobs instead of discarding those.
GitHub Actions seems to immediately throw away the new job when there are no runners at all. Generally, having runners of any status, `busy`, `idle`, or `offline` would prevent GitHub actions from failing jobs. But retaining `busy` or `idle` runners means that we need to keep runner pods running, which conflicts with our desired to scale to/from zero, hence we retain `offline` runners.
In this change, I enhanced the runnerreplicaset controller to create a registration-only runner on very beginning of its reconciliation logic, only when a runnerreplicaset is scaled to zero. The runner controller creates the registration-only runner pod, waits for it to become "offline", and then removes the runner pod. The runner on GitHub stays `offline`, until the runner resource on K8s is deleted. As we remove the registration-only runner pod as soon as it registers, this doesn't block cluster-autoscaler.
Related to #447
2021-05-02 16:11:36 +09:00
e l s e
KUBE_APISERVER_BIN = $( shell which kube-apiserver)
e n d i f
2021-03-31 09:23:16 +09:00
# find or download kubectl
kubectl :
feat: Support for scaling from/to zero (#465)
This is an attempt to support scaling from/to zero.
The basic idea is that we create a one-off "registration-only" runner pod on RunnerReplicaSet being scaled to zero, so that there is one "offline" runner, which enables GitHub Actions to queue jobs instead of discarding those.
GitHub Actions seems to immediately throw away the new job when there are no runners at all. Generally, having runners of any status, `busy`, `idle`, or `offline` would prevent GitHub actions from failing jobs. But retaining `busy` or `idle` runners means that we need to keep runner pods running, which conflicts with our desired to scale to/from zero, hence we retain `offline` runners.
In this change, I enhanced the runnerreplicaset controller to create a registration-only runner on very beginning of its reconciliation logic, only when a runnerreplicaset is scaled to zero. The runner controller creates the registration-only runner pod, waits for it to become "offline", and then removes the runner pod. The runner on GitHub stays `offline`, until the runner resource on K8s is deleted. As we remove the registration-only runner pod as soon as it registers, this doesn't block cluster-autoscaler.
Related to #447
2021-05-02 16:11:36 +09:00
i f e q ( , $( shell which kubectl ) )
2021-03-31 09:23:16 +09:00
i f e q ( , $( wildcard $ ( TEST_ASSETS ) /kubectl ) )
@{ \
set -xe ; \
INSTALL_TMP_DIR = $$ ( mktemp -d) ; \
cd $$ INSTALL_TMP_DIR ; \
wget https://github.com/kubernetes-sigs/kubebuilder/releases/download/v2.3.2/kubebuilder_2.3.2_$( OS_NAME) _amd64.tar.gz ; \
mkdir -p $( TEST_ASSETS) ; \
tar zxvf kubebuilder_2.3.2_$( OS_NAME) _amd64.tar.gz ; \
mv kubebuilder_2.3.2_$( OS_NAME) _amd64/bin/etcd $( TEST_ASSETS) /etcd ; \
mv kubebuilder_2.3.2_$( OS_NAME) _amd64/bin/kube-apiserver $( TEST_ASSETS) /kube-apiserver ; \
mv kubebuilder_2.3.2_$( OS_NAME) _amd64/bin/kubectl $( TEST_ASSETS) /kubectl ; \
rm -rf $$ INSTALL_TMP_DIR ; \
}
KUBECTL_BIN = $( TEST_ASSETS) /kubectl
e l s e
KUBECTL_BIN = $( TEST_ASSETS) /kubectl
e n d i f
feat: Support for scaling from/to zero (#465)
This is an attempt to support scaling from/to zero.
The basic idea is that we create a one-off "registration-only" runner pod on RunnerReplicaSet being scaled to zero, so that there is one "offline" runner, which enables GitHub Actions to queue jobs instead of discarding those.
GitHub Actions seems to immediately throw away the new job when there are no runners at all. Generally, having runners of any status, `busy`, `idle`, or `offline` would prevent GitHub actions from failing jobs. But retaining `busy` or `idle` runners means that we need to keep runner pods running, which conflicts with our desired to scale to/from zero, hence we retain `offline` runners.
In this change, I enhanced the runnerreplicaset controller to create a registration-only runner on very beginning of its reconciliation logic, only when a runnerreplicaset is scaled to zero. The runner controller creates the registration-only runner pod, waits for it to become "offline", and then removes the runner pod. The runner on GitHub stays `offline`, until the runner resource on K8s is deleted. As we remove the registration-only runner pod as soon as it registers, this doesn't block cluster-autoscaler.
Related to #447
2021-05-02 16:11:36 +09:00
e l s e
KUBECTL_BIN = $( shell which kubectl)
e n d i f