Add parameter to control instance count for Host JIT trace generation

[Francisco-Gamino]

Issue describing the changes in this PR

This PR introduces a new parameter jitTraceInstancesForRelease to the cold start pipeline that allows controlling the number of instances used during JIT trace generation for Host releases.

Problem
Currently, the pipeline uses the runInstances variable from coldstart.yml, which is set to 20 instances. When generating JIT traces for releases, this creates very large YAML files that cause pipeline failures when both Node and .NET apps are selected.

Solution

1. Added jitTraceInstancesForRelease Parameter

   • Allows specifying a smaller set of instances (e.g., 1,2,3) for JIT trace generation
   • Only applies when createJitTrace is set to true
   • Defaults to empty string, maintaining backward compatibility

2. Fixed Job Naming Validation

   • Updated job names to use _Instance prefix (e.g., HelloHttpNet9_Instance1)
   • Added space stripping logic to handle various input formats
   • Ensures compliance with Azure DevOps naming rules (alphanumeric + underscores, cannot start with number)

Implementation Details
The implementation uses a computed variable effectiveRunInstances that conditionally selects:

1. jitTraceInstancesForRelease when both createJitTrace is true and the parameter is provided
2. runInstances (default 20 instances) otherwise

Supported Input Formats
The parameter accepts three input formats with automatic space handling:

1. 1,2,3 -> Creates Instance1, Instance2, Instance3
2. 1, 2, 3 ->Spaces automatically removed -> Instance1, Instance2, Instance3
3. 1 , 2 , 3 -> All spaces automatically removed -> Instance1, Instance2, Instance3

Changes
host.coldstart.yml

1. Added jitTraceInstancesForRelease parameter with clear user guidance
2. Added effectiveRunInstances computed variable with conditional logic
3. Updated all stage loops to use effectiveRunInstances:
   • RunWindows stage
   • CalculateWindows stage (3 app configurations)
   • RunLinux stage
   • CalculateLinux stage (3 app configurations)

run-coldstart.yml

1. Updated job naming pattern to _Instance{id} format
2. Added replace function to strip spaces from instance IDs
3. Ensures valid Azure DevOps job names in all input scenarios

Usage Example
For release JIT trace generation (reduced instances):

createJitTrace: true
jitTraceInstancesForRelease: 1,2,3

[Copilot]

Pull request overview

This PR introduces a new jitTraceInstancesForRelease parameter to control the number of instances used during JIT trace generation for Host releases, addressing pipeline failures caused by large YAML files when using the default 20 instances. The implementation also updates job naming to comply with Azure DevOps naming conventions.

Key changes:

• Added jitTraceInstancesForRelease parameter allowing users to specify a smaller set of instances (e.g., "1,2,3") for JIT trace generation
• Introduced effectiveRunInstances computed variable that conditionally selects between the new parameter and the default runInstances
• Updated job naming from {functionAppName}_{instanceId} to {functionAppName}_Instance{instanceId} with space-stripping logic

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
eng/ci/host.coldstart.yml	Added new parameter jitTraceInstancesForRelease, introduced effectiveRunInstances computed variable, and updated all stage loops to use the new variable instead of runInstances
eng/ci/templates/official/jobs/run-coldstart.yml	Updated job naming pattern to include "_Instance" prefix and added replace() function to strip spaces from instance IDs

Critical Issues Found: The implementation has several critical bugs that will cause pipeline failures:

1. Space handling is broken: The replace() function only strips spaces from job names, not from the instanceId parameter values, breaking all conditional checks that compare instanceId with '1'
2. Job naming change breaks dependencies: The new naming pattern breaks stageDependencies references in process-coldstart.yml (which is not included in this PR but needs updating)
3. Invalid environment variables: Spaces in instance IDs will create invalid environment variable names in process-coldstart.yml
4. PR description is incorrect: Claims that spaces are automatically handled for inputs like "1, 2, 3", but this is not true in the implementation

Comments suppressed due to low confidence (1)

eng/ci/host.coldstart.yml:101

• The space stripping with replace() only affects the job name but does not strip spaces from the instanceId parameter value itself. This will cause critical failures in conditional checks throughout this template that compare instanceId with '1'.

For example, if the user provides "1, 2, 3" as input:

• After split(), the first appId will be "1" and the second will be " 2" (with leading space)
• This " 2" gets passed as instanceId parameter
• Line 36, 42, 74, 80, 90, etc. use eq(parameters.instanceId, '1') comparisons
• These comparisons will fail for the first instance if it has any surrounding spaces (e.g., " 1" or "1 ")

The ${{ appId }} in host.coldstart.yml should be trimmed before being passed as instanceId. However, Azure DevOps YAML doesn't have a built-in trim function at the template expression level. Consider one of these solutions:

1. Document that the parameter must be provided without spaces (e.g., "1,2,3" only)
2. Add a preprocessing step to normalize the input
3. Strip spaces in the variable definition itself using replace in the effectiveRunInstances variable

      - ${{ each appId in split(variables.effectiveRunInstances, ',') }}:
        - ${{ if eq(parameters.includeHelloHttpNet9, true) }}:
          - template: /eng/ci/templates/official/jobs/run-coldstart.yml@self
            parameters:
              description: .NET9 Web Application
              functionAppName: HelloHttpNet9
              instanceId: ${{ appId }} 

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

[jviau]

@Francisco-Gamino, do you need the run instances to be configurable when generating the JIT trace files? Or would it be sufficient to just always set to 3 in that case? If so, then this pipeline could use templating to alter runInstances based on if pipeline is enqueued for JIT or not.

[kshyju]

@Francisco-Gamino, do you need the run instances to be configurable when generating the JIT trace files? Or would it be sufficient to just always set to 3 in that case? If so, then this pipeline could use templating to alter runInstances based on if pipeline is enqueued for JIT or not.

yea, hard coded 3 instances are good, when "create jit trace" is checked. No need for user to provide it.