ci: pass openapi-max-workers through deploy-kotlin{,-v2} to component-service-profile

[JesperTerkelsen]

Summary

Forwards the openapi-max-workers input added in #279 from the deploy-kotlin and deploy-kotlin-v2 umbrella workflows down into component-service-profile-kotlin, where it actually maps to ./gradlew --max-workers=<n>.

Why this is needed

Without this passthrough, the input added in #279 is unreachable from any service repo. Service repos consume the umbrella workflows (deploy-kotlin.yml / deploy-kotlin-v2.yml), not component-service-profile-kotlin.yml directly:

service-api-gateways/.../deploy_partner_api_production.yml
  └─ uses: monta-app/github-workflows/.github/workflows/deploy-kotlin.yml@main   # umbrella
        └─ uses: ./.github/workflows/component-service-profile-kotlin.yml         # leaf — has the input

So the umbrella has to declare and forward the input.

Diff

Same shape in both deploy-kotlin.yml and deploy-kotlin-v2.yml:

       update-service-profile:
         required: false
         type: boolean
         default: true
         description: 'Use generated openapi spec to generate linkerd service profile and update the service helm chart'
+      openapi-max-workers:
+        required: false
+        type: string
+        default: ''
+        description: |
+          Optional cap on Gradle parallelism for the OpenAPI build step in the
+          update-service-profile job. Forwarded to component-service-profile-kotlin.
+          Set to e.g. "2" on multi-module repos that OOM the runner during
+          concurrent kapt. Empty string keeps default behavior.
...
   update-service-profile:
     name: Update Service Profile
     ...
     uses: ./.github/workflows/component-service-profile-kotlin.yml
     with:
       service-identifier: ${{ inputs.service-identifier }}
       stage: ${{ inputs.stage }}
       gradle-module: ${{ inputs.gradle-module }}
       java-version: ${{ inputs.java-version }}
+      openapi-max-workers: ${{ inputs.openapi-max-workers }}

Default is '' so existing callers see no behavior change.

Caller-side change (separate PR in service-api-gateways)

After this lands, each deploy_*.yml in service-api-gateways will gain openapi-max-workers: '2' to avoid the OOM in the Update Service Profile / Build OpenAPI spec step (failing runs: 25171374143, 25236336830, 25236336844).

Test plan

• CI green
• After merge, the follow-up service-api-gateways PR can pass openapi-max-workers: '2' and the Update Service Profile job stops OOMing

🤖 Generated with Claude Code