Feat/azure pipelines license check

[yogita-mehta]

This PR adds an optional enableLicenseCheck parameter to the Azure Pipelines scaler. When enabled, the scaler queries the Azure DevOps organization's parallel job license usage and caps the reported queue length to the number of currently available licenses. This prevents KEDA from over-provisioning agent pods (and reserving resources like IPs) for jobs that Azure DevOps cannot actually schedule due to license limits.

This is disabled by default (enableLicenseCheck: false) to preserve existing behavior for users who don't need it.

If the license usage lookup fails, the scaler logs the error and gracefully falls back to the uncapped queue length rather than failing the scaler entirely.

Testing Done:

• Added 4 new unit tests in azure_pipelines_scaler_test.go verifying the limit, skip, and fallback behaviors.
• Added a new E2E test suite specifically for azure_pipelines_license_check in the latest commit.

Checklist

• When introducing a new scaler, I agree with the scaling governance policy
• I have verified that my change is according to the deprecations & breaking changes policy
• Tests have been added (if applicable)
• Ensure make generate-scalers-schema has been run to update any outdated generated files
• Changelog has been updated and is aligned with our changelog requirements, only when the change impacts end users
• A PR is opened to update our Helm chart (repo) (if applicable, ie. when deployment manifests are modified)
• A PR is opened to update the documentation on (repo) (if applicable)
• Commits are signed with Developer Certificate of Origin (DCO - learn more)

Fixes #5573

Relates to #

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[github-actions]

Thank you for your contribution! 🙏

Please understand that we will do our best to review your PR and give you feedback as soon as possible, but please bear with us if it takes a little longer as expected.

While you are waiting, make sure to:

• Add an entry in our changelog in alphabetical order and link related issue
• Update the documentation, if needed
• Add unit & e2e tests for your changes
• GitHub checks are passing
• Is the DCO check failing? Here is how you can fix DCO issues

Once the initial tests are successful, a KEDA member will ensure that the e2e tests are run. Once the e2e tests have been successfully completed, the PR may be merged at a later date. Please be patient.

Learn more about our contribution guide.

[yogita-mehta]

Hi @rickbrouwer / @JorTurFer,

I have recreated this PR to ensure it strictly follows the repository's default pull request template and checklist (my sincere apologies for messing up the template in the previous PR!).

All the code, including the 4 new unit tests and the newly added E2E test suite for the azure_pipelines_license_check feature, is ready in this branch.

Could you please take a look and trigger the E2E test pipelines when you have a moment? Thank you for your patience and guidance!

[rickbrouwer]

Ensure “make generate-scalers-schema” has been run to update the outdated generated files

[yogita-mehta]

Hi @rickbrouwer,
I have successfully generated the updated schema files, pushed the changes, and updated the PR checklist. Let me know if you need anything else!

[rickbrouwer]

Can you indicate what you did to create the schema’s?

[yogita-mehta]

Hi @rickbrouwer,

To create the updated schema files, I ran the make generate-scalers-schema command locally using Git Bash on Windows.

I also noticed that the validate - s390x CI check is still failing. The log at the test-summary step shows ENOENT: no such file or directory, open 'report.xml'. I am currently digging into the preceding steps in the CI logs to find the exact compilation or test failure that caused the pipeline to break before the test report could be generated.

[rickbrouwer]

Ok. You must run that command from the root in the KEDA directory on your working branch.