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

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

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.

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