feat(resources:set): allow --count for horizontally scalable services - #185
pjcdawkins wants to merge 4 commits into
Conversation
Services such as database replicas can be scaled manually through the sizing API, but the CLI rejected any instance count for a service. Allow the instance count of a service when the deployment reports supports_horizontal_scaling for it, in both --count and the interactive form. Services without the flag now get a "does not support horizontal scaling" error. Tasks and the autoscaling check are unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
There was a problem hiding this comment.
Warning
Changes suggested — 🟡 2 warnings
🔍 Full review · 2 files reviewed
Verification
validateInstanceCountstill rejects a Task before the new horizontal-scaling check, so tasks keep the "cannot be changed" message.- For a scalable service, the autoscaling-enabled check and the instance limit check still run after the new service check.
- The execute loop and
validateInstanceCountboth usesupportsInstanceCount, so--countand the interactive prompt apply the same rule to services. computeMemoryCPUStorageDiffalready multiplies CPU and memory by instance count for any group, so trial-limit checks cover service count changes.
The new testValidateInstanceCount in ResourcesSetTest.php covers validateInstanceCount for apps, workers, tasks and services with and without the flag, including the autoscaling and limit cases. It runs in the legacy-php CI job (PHPUnit, plus phpstan and php-cs-fixer). No test covers the execute-loop path for services, including the interactive prompt and the update payload.
Review details
- Commit: 151c792
- Model: claude-opus-5-5
Review 1 of 10 for this pull request · View the full run
A service may have no instance_count. The interactive form then compared the accepted default of 1 against null and queued a no-op update. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
There was a problem hiding this comment.
Note
Reviewed — No new issues found · 1 still open
🔁 Incremental · 1 file reviewed
Outstanding from earlier reviews:
- 🟡 #4117201704 —
legacy/src/Command/Resources/ResourcesSetCommand.php:560: Users may be allowed to request scaling that the project cannot perform. —supportsInstanceCountstill checks only the deployment'ssupports_horizontal_scalingflag and not the project capability. The author says this is intentional because the API does not gate manual sizing on that capability. The disagreement withautoscaling:setremains.
Verification
$currentCount = $properties['instance_count'] ?? 1is read once. The --count comparison, the prompt default and the interactive comparison all use it, so a missing key no longer triggers an undefined-key warning.- Accepting the default '1' for a service with no instance_count now compares int 1 to int 1, so no update is queued.
validateInstanceCountreturns an int, which keeps the strict!==comparison correct. - The simplified --count check
$instanceCount !== $currentCountbehaves the same as the old compound condition that special-cased an unset count with a requested count of 1.
The diff adds 35 lines to legacy/tests/Command/Resources/ResourcesSetTest.php for the service count path. I read the command change and the QuestionHelper/validator types, but not the new test bodies. I did not run the tests.
Review 2 of 10 for this pull request · View the full run
Add integration tests with a deployment holding an app, two workers (one autoscaled), three services (one horizontally scalable with no instance_count, one without a disk) and a task. They check the PATCH body or errors for --count, --size, --disk and --object-storage on each container type, wildcards, the instance limit, autoscaling, unknown containers, --service filtering and --dry-run, and that the interactive form asks for a count only for a scalable service. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Add to mockapi: - Environment.SetNextDeployment, serving the next deployment as raw data with self and #edit links, and recording PATCH bodies, which Handler.DeploymentPatches returns - Environment.SetAutoscalingSettings, serving the settings and adding the #autoscaling and #manage-autoscaling links - Project.Settings, served at the project's /settings path Use them in the resources and autoscaling integration tests, and merge the three resources setup helpers into setUpResourcesProject, with nextDeployment, serveAPI and deploymentPatch helpers. Remove the organization profile stubs: resources:set no longer requests the profile. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
📋 PR Summary This PR lets Changes
|
Services such as database replicas can be scaled manually through the sizing API, but
resources:setrejected any instance count for a service:This allows
--count(and the interactive prompt) for a service when the deployment reportssupports_horizontal_scaling: truefor it. Other services get a "does not support horizontal scaling" error. Tasks, the autoscaling-enabled check, and the instance limit are unchanged.🤖 Generated with Claude Code