feat(runner): add source parameter to distinguish between scale-up and pool lambda

[stuartp44]

This pull request updates the way runner creation is tracked and tagged by introducing an explicit source parameter to distinguish between runners created by the scale-up lambda and those created by the pool lambda. The changes ensure that the runner creation flow and related tests consistently use this new source field.

Runner creation and tagging improvements:

• Added a source field ('scale-up-lambda' | 'pool-lambda') to RunnerConfig, RunnerInputParameters, and related test interfaces to explicitly track the origin of runner creation. [1] [2] [3]
• Updated the runner creation logic in createInstances and createRunners to use the new source field for the ghr:created_by tag, replacing previous logic based on runner count. [1] [2]

Test enhancements:

• Modified and added tests in runners.test.ts to verify correct behaviour when the source parameter is specified, including both single and multiple instance fleet creation. [1] [2] [3] [4] [5]
• Updated pool adjustment tests to pass the source argument and verify its usage in runner creation calls. [1] [2] [3] [4]

Pool and scaling logic:

• Changed the pool adjustment logic in pool.ts to always pass 'pool-lambda' as the source when topping up the pool.
• Ensured scale-up runner logic in scale-up.test.ts and related code passes 'scale-up-lambda' as the source for created runners.

These changes collectively improve the clarity and reliability of runner source tracking throughout the control-plane codebase.

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

[npalm]

@stuartp44 can you make also clear what bug / issue is addressed. I think the batch intruduced to handle scaling is causing runners are marekd with pool instead of scale-up

[Copilot]

Pull request overview

This PR improves runner origin tracking in the control-plane by introducing an explicit source field that distinguishes between runners created by the scale-up lambda vs the pool lambda, and uses that field to drive the ghr:created_by EC2 tag.

Changes:

• Added source: 'scale-up-lambda' | 'pool-lambda' to runner input/config types and threaded it through runner creation calls.
• Updated EC2 instance tagging to set ghr:created_by from runnerParameters.source instead of inferring from runner count.
• Updated/added tests to assert the new source behavior for both pool top-ups and fleet creation.

Reviewed changes

Copilot reviewed 6 out of 7 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
lambdas/functions/control-plane/src/scale-runners/scale-up.ts	Extends createRunners to accept and forward a source value (defaulting to scale-up-lambda).
lambdas/functions/control-plane/src/scale-runners/scale-up.test.ts	Updates expected runner parameters to include source.
lambdas/functions/control-plane/src/pool/pool.ts	Passes 'pool-lambda' when creating runners during pool top-up.
lambdas/functions/control-plane/src/pool/pool.test.ts	Updates expectations to include the new source argument in createRunners calls.
lambdas/functions/control-plane/src/aws/runners.ts	Sets the EC2 tag ghr:created_by directly from runnerParameters.source.
lambdas/functions/control-plane/src/aws/runners.test.ts	Adds/updates tests to validate correct tagging for both scale-up-lambda and pool-lambda sources.
lambdas/functions/control-plane/src/aws/runners.d.ts	Adds the source field to RunnerInputParameters.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[stuartp44]

@npalm its in the issue attached. TLDR, it's because we have some runner types that do not have pools but are getting tagged with created by "pool-lambda", which is incorrect.

[guicaulada]

Looks good to me! The change is well-scoped and well-tested.

Making source explicit feels better than relying on numberOfRunners.

I have a few minor suggestions and questions, but no blockers.

If you could link the issue directly on the PR body (e.g. Fixes #5053) it would make it easier to find.