github-runner-scaler always scales with default labels

[leevilehtonen]

Report

Current github-runner-scaler implementation seems to scale the runner always with default labels like self-hosted even when explicit labels are provided for labels configuration. Either this seems like an undocumented feature or a bug in the implementation, as the current documentation states:

labels - The list of runner labels to scale on, separated by comma. (Optional)

Either way, it should be possible to not scale on the default labels as it's possible to register a self hosted runner without default labels by providing --no-default-labels option (and optional explicit labels) when registering the runner with config.sh. (With the current logic it leads to a case where github-runner-scaler scales always with default labels but runner is not registered to pick up jobs with default labels).

Expected Behavior

github-runner-scaler respects the provided labels only and does not consider any default labels then

Actual Behavior

github-runner-scaler uses both the provided labels as well as default labels

Steps to Reproduce the Problem

1. Set labels as foo
2. Create a Github Workflow with a job having runs-on: self-hosted
3. github-runner-scaler scales on this job even though it should only scale on jobs having run-on: foo

Logs from KEDA operator

example

KEDA Version

2.14.0

Kubernetes Version

None

Platform

Microsoft Azure

Scaler Details

Github Runner Scaler

Anything else?

No response

[JorTurFer]

Yeah, current implementation is evaluation if the job doesn't contain the given labels and neither the default labels

keda/pkg/scalers/github_runner_scaler.go

Line 30 in 85d4dca

var reservedLabels = []string{"self-hosted", "linux", "x64"}

keda/pkg/scalers/github_runner_scaler.go

Lines 614 to 621 in 85d4dca

	func canRunnerMatchLabels(jobLabels []string, runnerLabels []string) bool {
	for _, jobLabel := range jobLabels {
	if !contains(runnerLabels, jobLabel) && !contains(reservedLabels, jobLabel) {
	return false
	}
	}
	return true
	}

I guess that in this case, the default label is accepted and that's why you see the behaviour.

Are you willing to open a PR supporting to not take them into account @leevilehtonen ?

FYI @Eldarrin

[leevilehtonen]

Yeah, current implementation is evaluation if the job doesn't contain the given labels and neither the default labels

keda/pkg/scalers/github_runner_scaler.go

Line 30 in 85d4dca

var reservedLabels = []string{"self-hosted", "linux", "x64"}

keda/pkg/scalers/github_runner_scaler.go

Lines 614 to 621 in 85d4dca

	func canRunnerMatchLabels(jobLabels []string, runnerLabels []string) bool {
	for _, jobLabel := range jobLabels {
	if !contains(runnerLabels, jobLabel) && !contains(reservedLabels, jobLabel) {
	return false
	}
	}
	return true
	}

I guess that in this case, the default label is accepted and that's why you see the behaviour.

Are you willing to open a PR supporting to not take them into account @leevilehtonen ?

FYI @Eldarrin

@JorTurFer Could be doable :) What do you think about the fix itself, like removing the second condition could be in a way breaking change for those who have been relying on to this behaviour. So would it actually make sense to create a new option similar that is in runner registration (--no-default-labels:
https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/using-self-hosted-runners-in-a-workflow#about-self-hosted-runner-labels) which would control if default labels are considered in scaling.

[zroubalik]

Yeah, we should be backwards compatible if that's doable.