# Machine tag and delete endpoints, hidden secret values, and steps that fail when nothing matches Source: https://www.jawsdeploy.net/changelog/api-endpoints-hidden-secrets-no-targets Three new groups of REST endpoints, secrets that cannot be read back once saved, and a choice of what a step does when it has nowhere to run. ## REST API Three new groups of endpoints, so a pipeline can do these without opening the UI. ### Machine tags [Assign a tag](https://www.jawsdeploy.net/rest-api/machines-tag-assign) adds one tag to a machine and [Unassign a tag](https://www.jawsdeploy.net/rest-api/machines-tag-unassign) removes one, leaving the machine's other tags alone. Both are safe to repeat: assigning a tag the machine already has, or removing one it does not have, is not an error. [Replace a machine's tags](https://www.jawsdeploy.net/rest-api/machines-tags-replace) sets the complete list. If any tag ID in it is not from the machine's workspace, nothing is changed. ### Delete a package version [Delete a package version](https://www.jawsdeploy.net/rest-api/package-store-delete) removes one version of a package from the workspace's built-in package store and keeps the other versions. Packages in external feeds are not affected. It needs the package delete permission for the workspace, or full control of it. Organizations set up before the *Package manager* role existed now have it too, so it can be assigned to a service account. ### Delete a project variable [Delete a project variable](https://www.jawsdeploy.net/rest-api/project-variable-delete) removes a variable created in the project, together with all of its values. Deployments started afterwards no longer see it. Workspace variables a project imported are removed with the existing unimport endpoint. ## Hide secret values once saved A new switch under **Settings > Organization > Secret variables** makes saved secret values write-only: they can no longer be revealed in the UI or read back over the REST API, only replaced. Deployments are not affected. The switch is on by default for organizations created from now on. Existing organizations keep their current behaviour until they turn it on. ### Who can still read secrets Users and service accounts that need to read secrets can be given the new *Secret reader* role, for all workspaces or for one workspace. Full control of a workspace does not include it, so a CI key that writes a secret cannot read it back. ### Over the REST API While the switch is on, [List workspace variables](https://www.jawsdeploy.net/rest-api/workspace-variables-list) returns `null` for secret values. To change a secret's scope without sending the value again, update the value and leave out `theValue`. A secret variable can only be changed to another type by someone who can read secrets, because the change would make its stored values readable. ## When no targets match Until now, a step whose machine, tag or worker filters matched no target was quietly skipped, and a deployment of such steps could finish `Completed` having done nothing. Each step now has a **When no targets match** setting: - **Skip** - the default and the old behaviour. - **Skip and log a warning**. - **Fail the step** - counts like any other failure, so the step's failure setting applies. Rolling groups have the same setting, and it covers all of their member steps. Over the REST API it is `onNoTargets` on [Update a project step](https://www.jawsdeploy.net/rest-api/project-step-update) and the rolling group endpoints. The setting never applies to a step skipped on purpose, such as a disabled step or one limited to other environments. A deployment started for a chosen set of machines also never fails this way: a step left with nothing to run on is skipped and the log says why. ## More MCP tools AI assistants connected through [MCP](https://www.jawsdeploy.net/features/mcp) can now: - create a release (`create_release`), so a project can go from building to deploying in one conversation - limit a step to environments, machines, machine tags, cloud target tags or a worker tag (`set_project_step_targets`) - replace a machine's tags (`set_machine_tags`) - delete a package version (`delete_package`) or a variable (`delete_variable`) Secret variables cannot be deleted or changed to another type over MCP. Manage them in the UI, so their values never end up in an AI transcript. ## Fixed ### Workspace admins could not deploy Users and service accounts with the *Workspace admin* role, and every MCP account, were refused by the **Deploy** button, by `preview_deploy` and `trigger_deploy`, and by the release deploy endpoint, although they could create releases. Full control of the organization or of the workspace now allows deploying, as it already allowed the other deployment actions. ### Environment variables leaked between PowerShell 7 steps PowerShell 7 steps run inside the agent, so a script that set `$env:` changed the agent itself. The change stayed for later steps and deployments until the agent restarted. Paths that grew on every run, such as `PSModulePath`, could eventually stop any shell from starting with an "environment variable name or value is too long" error. The agent now puts its environment back when the script finishes and logs which variables it reset. To pass a value to a later step, use `Set-JawsOutputValue`. Takes effect once your agents are updated to this release. ### Steps after a failed step A step set to run only when **All previous steps succeeded** is now also skipped when an earlier step finished `Failed` or `TimedOut` without logging an error. ### Clearer step name errors An invalid step name is now rejected with the characters that broke the rule, so a name like `Shop.Web` is easy to fix. ### Revoked MCP access stops sooner A deleted service account or a revoked key stops working over MCP within a minute, even when an assistant is using it constantly.