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)
2022-08-23 06:40:16 +02:00
VERSION ?= dev
2022-11-03 14:40:06 +09:00
RUNNER_VERSION ?= 2.299.1
2021-12-29 01:23:35 +00:00
TARGETPLATFORM ?= $( shell arch)
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 ?=
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
TEST_EPHEMERAL ?= false
2022-04-24 02:47:00 +01:00
SYNC_PERIOD ?= 1m
2021-06-22 17:10:09 +09:00
USE_RUNNERSET ?=
KUBECONTEXT ?= kind-acceptance
CLUSTER ?= acceptance
CERT_MANAGER_VERSION ?= v1.1.1
2021-12-08 22:53:50 +00:00
KUBE_RBAC_PROXY_VERSION ?= v0.11.0
2022-10-04 20:30:43 +09:00
SHELLCHECK_VERSION ?= 0.8.0
2021-05-01 08:10:57 +02:00
2020-01-28 15:03:23 +09:00
# Produce CRDs that work back to Kubernetes 1.11 (no version conversion)
2021-12-11 20:49:47 +09:00
CRD_OPTIONS ?= "crd: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
2022-10-04 20:30:43 +09:00
TOOLS_PATH = $( PWD) /.tools
2021-03-31 09:23:16 +09:00
2022-11-03 05:57:04 -06:00
OS_NAME := $( shell uname -s | tr A-Z a-z)
2022-11-25 21:08:24 -07:00
# The etcd packages that coreos maintain use different extensions for each *nix OS on their github release page.
# ETCD_EXTENSION: the storage format file extension listed on the release page.
# EXTRACT_COMMAND: the appropriate CLI command for extracting this file format.
i f e q ( $( OS_NAME ) , d a r w i n )
ETCD_EXTENSION := zip
EXTRACT_COMMAND := unzip
e l s e
ETCD_EXTENSION := tar.gz
EXTRACT_COMMAND := tar -xzf
e n d i f
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
2022-09-20 20:08:22 -04:00
lint :
docker run --rm -v $( PWD) :/app -w /app golangci/golangci-lint:v1.49.0 golangci-lint run
2021-06-27 16:28:07 +09:00
GO_TEST_ARGS ?= -short
2020-01-28 15:03:23 +09:00
# Run tests
2022-10-04 20:30:43 +09:00
test : generate fmt vet manifests shellcheck
2021-06-27 16:28:07 +09:00
go test $( GO_TEST_ARGS) ./... -coverprofile cover.out
2022-05-19 21:34:23 +09:00
go test -fuzz= Fuzz -fuzztime= 10s -run= Fuzz* ./controllers
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.
2021-09-10 10:07:04 +01:00
manifests : manifests -gen -crds chart -crds
2020-10-15 02:39:46 +03:00
2021-09-23 18:03:35 +01:00
manifests-gen-crds : controller -gen yq
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
2021-09-23 18:03:35 +01:00
for YAMLFILE in config/crd/bases/actions*.yaml; do \
2022-07-14 21:59:13 -04:00
$( YQ) '.spec.preserveUnknownFields = false' --inplace " $$ YAMLFILE " ; \
2021-09-23 18:03:35 +01:00
done
2020-01-28 15:03:23 +09:00
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 ./...
# 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 = "./..."
2022-10-04 20:30:43 +09:00
# Run shellcheck on runner scripts
shellcheck : shellcheck -install
2022-11-01 20:30:10 +09:00
$( TOOLS_PATH) /shellcheck --shell bash --source-path runner runner/*.sh
2022-10-04 20:30:43 +09:00
2020-10-05 11:26:46 +11:00
docker-buildx :
2022-04-27 08:21:02 +01:00
export DOCKER_CLI_EXPERIMENTAL = enabled ; \
export DOCKER_BUILDKIT = 1
2020-10-05 11:26:46 +11:00
@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 } \
2022-08-23 06:40:16 +02:00
--build-arg VERSION = ${ VERSION } \
2020-10-05 11:26:46 +11:00
-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 }
2021-12-08 22:53:50 +00:00
kind load docker-image quay.io/brancz/kube-rbac-proxy:$( KUBE_RBAC_PROXY_VERSION) --name ${ CLUSTER }
2021-06-22 17:10:09 +09:00
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-12-08 22:53:50 +00:00
docker pull quay.io/brancz/kube-rbac-proxy:$( KUBE_RBAC_PROXY_VERSION)
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 } \
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
TEST_EPHEMERAL = ${ TEST_EPHEMERAL } \
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
2022-11-01 20:30:10 +09:00
acceptance/runner/startup :
cd test/startup/ && bash test.sh
2022-03-22 19:02:51 +00:00
2021-06-29 17:52:43 +09:00
# We use -count=1 instead of `go clean -testcache`
# See https://terratest.gruntwork.io/docs/testing-best-practices/avoid-test-caching/
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
.PHONY : e 2e
e2e :
2021-06-29 17:52:43 +09:00
go test -count= 1 -v -timeout 600s -run '^TestE2E$$' ./test/e2e
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
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 ; \
2022-05-19 18:33:31 +09:00
go install sigs.k8s.io/controller-tools/cmd/controller-gen@v0.7.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
2021-09-23 18:03:35 +01:00
# find or download yq
# download yq if necessary
# Use always go-version to get consistent line wraps etc.
yq :
i f e q ( , $( wildcard $ ( GOBIN ) /yq ) )
echo "Downloading yq"
@{ \
set -e ; \
YQ_TMP_DIR = $$ ( mktemp -d) ; \
cd $$ YQ_TMP_DIR ; \
go mod init tmp ; \
2022-07-14 21:59:13 -04:00
go install github.com/mikefarah/yq/v4@v4.25.3 ; \
2021-09-23 18:03:35 +01:00
rm -rf $$ YQ_TMP_DIR ; \
}
e n d i f
YQ = $( GOBIN) /yq
2022-10-04 20:30:43 +09:00
# find or download shellcheck
# download shellcheck if necessary
shellcheck-install :
i f e q ( , $( wildcard $ ( TOOLS_PATH ) /shellcheck ) )
echo "Downloading shellcheck"
@{ \
set -e ; \
SHELLCHECK_TMP_DIR = $$ ( mktemp -d) ; \
cd $$ SHELLCHECK_TMP_DIR ; \
2022-11-03 05:57:04 -06:00
curl -LO https://github.com/koalaman/shellcheck/releases/download/v$( SHELLCHECK_VERSION) /shellcheck-v$( SHELLCHECK_VERSION) .$( OS_NAME) .x86_64.tar.xz ; \
tar Jxvf shellcheck-v$( SHELLCHECK_VERSION) .$( OS_NAME) .x86_64.tar.xz ; \
2022-10-04 20:30:43 +09:00
cd $( CURDIR) ; \
mkdir -p $( TOOLS_PATH) ; \
mv $$ SHELLCHECK_TMP_DIR/shellcheck-v$( SHELLCHECK_VERSION) /shellcheck $( TOOLS_PATH) / ; \
rm -rf $$ SHELLCHECK_TMP_DIR ; \
}
e n d i f
SHELLCHECK = $( TOOLS_PATH) /shellcheck
2021-03-31 09:23:16 +09:00
# 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 ; \
2022-11-25 21:08:24 -07:00
wget https://github.com/coreos/etcd/releases/download/v3.4.22/etcd-v3.4.22-$( OS_NAME) -amd64.$( ETCD_EXTENSION) ; \
2021-03-31 09:23:16 +09:00
mkdir -p $( TEST_ASSETS) ; \
2022-11-25 21:08:24 -07:00
$( EXTRACT_COMMAND) etcd-v3.4.22-$( OS_NAME) -amd64.$( ETCD_EXTENSION) ; \
mv etcd-v3.4.22-$( OS_NAME) -amd64/etcd $( TEST_ASSETS) /etcd ; \
2021-03-31 09:23:16 +09:00
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/kube-apiserver $( TEST_ASSETS) /kube-apiserver ; \
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/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