Description
Updates a project's general settings. Pass only the fields you want to change.
The same call also sets the project's two deployment timeout overrides, which have their own partial-update rules. See Deployment limits below.
Parameters
| Name | In | Type | Required | Description |
|---|---|---|---|---|
projectId |
body | string | yes | ID of the project. |
name |
body | string | no | New name. |
description |
body | string | no | New description. |
maxDeploymentDurationSeconds |
body | integer | no | Wall-clock cap on a whole deployment of this project, in seconds. 0 removes the override and restores the system default. See Deployment limits below. |
stepIdleMaxSeconds |
body | integer | no | How long one step may go without the agent reporting progress before it is interrupted, in seconds. 0 removes the override and restores the system default. See Deployment limits below. |
Deployment limits
Two optional per-project overrides of timeouts that otherwise come from server configuration. Both are in seconds.
maxDeploymentDurationSeconds: a wall-clock cap on the whole deployment, whether or not it is making progress. This is what stops a hung deployment holding one of the organization's parallel deployment slots indefinitely.stepIdleMaxSeconds: how long a single step may go without the agent reporting progress before it is interrupted. The interruption is written to the deployment log, naming the timeout that was applied.
Each takes three kinds of value, so one limit can be set without restating the other:
- omitted, or
null: leave whatever is stored alone. 0: remove this project's override, so the configured default applies again.- a positive number: use this value for this project.
No value means never apply this limit. For the duration cap, that would allow the same hang the cap exists to prevent, so a project that needs more time sets a larger number.
The ceiling is 2000000 seconds, a little under 24 days. Past that the runner cannot arm its own timer, and only the scheduler's backstop would stop the deployment. The backstop marks the deployment failed and frees the slot, but can't stop the work already running. A larger value is refused up front rather than accepted and quietly not honoured.
Both limits are validated before anything is written, and the general settings and the limits are saved in one transaction. A request that renames the project and carries an invalid limit therefore changes nothing. The rename is not saved before the request fails.
Errors
| Status | Meaning |
|---|---|
400 |
Invalid projectId or validation failure. |
401 |
Missing or invalid Basic auth credentials, or the service account lacks the required role. |
400 |
A deployment limit is negative. The response reads deployment limits cannot be negative - use 0 to reset a limit to the system default, and nothing is changed. |
400 |
A deployment limit is above 2000000 seconds. The message names the ceiling and the reason for it, and nothing is changed. |