Compare releases

Highlights

Spaces

To bring in the new year, we are shipping our latest feature. Spaces is a comprehensive set of user interface, API and permission system changes designed to make it easier to configure deployments in busy organizations.

From our documentation:

Spaces let you partition your Octopus server so that different teams can only access the projects, environments, and infrastructure they work with from the spaces they are members of.

Teams & Permissions

We have re-designed the way permissions are assigned to Teams, making it easier than ever to configure and manage permissions for your users. As part of this we have rewritten much of the code that enforces these permissions so that we can make sure Octopus keeps your data safe. There are a few breaking changes involved here, so customers with complex permission configurations may want to pay careful attention to the release notes.

Breaking Changes

Before upgrading to this release, there are some breaking changes in behaviour that you need to be aware of.

Tentacle

Some tentacle operations now necessarily act within a space and the CLI commands accept an optional spaceName parameter. These commands are the register-with, register-worker, deregister-from, deregister-worker and show-configuration commands. Since the deregister-* commands act within a single space, and a single Tentacle can register machines in multiple spaces, these commands no longer remove trust for the Octopus Server. To remove trust, the command Tentacle.exe configure --remove-trust=... must instead be used.

API Changes

A number of API route changes were made in this release. Most routes now include a segment that represents the target Space. We provide a Default Space for backwards compatibility with the old routes.

Disabling the Default Space will turn off backwards compatibility. Anything that leans on the old API routes, integrations, extensions and tools may break when the default spaces is disabled. More information here

Many of these changes are also reflected in Octopus.Client, so it is recommended your integrations update to the latest version of Octopus.Client (at least 5.0.0).

IsMultiTenancyEnabled

The property representing whether multi-tenancy was enabled is no longer exposed through the features endpoint (/api/featuresconfiguration) but is now exposed through the tenancy status endpoint (/api/tenants/status or /api/{spaceId}/tenants/status).

Built in Repository & Feeds

The endpoint responsible for fetching and configuring settings related to the built in package repository (/api/repository/configuration) has been removed. Instead, the built in package repository settings are managed the same way as other feed types, through the feeds api (/api/feeds/{feedId}), where the {feedId} is the Id of the built in package repository. The built in package repository endpoint has moved from /api/serverstatus/nuget to /api/feeds/stats or /api/{spaceId}/feeds/stats

ServerTask links

The Links collection on Tasks (TaskResource) no longer contains Artifacts and Interruptions links for the subset of task types for which they do not apply (i.e. “System” tasks).

UserRoles

UserRoles (UserRoleResource) used to contain a single collection of GrantedPermissions, but now instead contains separate collections for permissions that apply within a space (GrantedSpacePermissions), and permissions that apply at the system level (GrantedSystemPermissions). Similarly, PermissionDescriptions has been replaced by SpacePermissionDescriptions and SystemPermissionDescriptions

Teams

Teams no longer contain scope properties (ProjectGroups, Projects, Environments and Tenants), nor do they reference UserRole. These concepts have been replaced by the new entity type ScopedUserRole.

ScopedUserRoles

This new entity type exists at /api/scopeduserroles. It represents an application of a UserRole to a Team. It also includes the scope properties (ProjectGroups, Project, Environment and Tenants) that apply for that UserRole. This enables UserRoles with different scoped applied to the same Team (i.e. the same group of Users), and also allows the same Team to have access to different Spaces.

Artifacts

Artifacts (Artifactresource) no longer contains RelatedDocumentIds. Instead there is a new property called ServerTaskId to indicate which ServerTask the Artifact was collected from. Artifacts can only be associated with AdHoc Script tasks and Deployment tasks.

Permission changes

The implementation of our permissions system was changed in order to support Spaces. At the same time, we took the opportunity to apply permissions more consistently, so that we could reduce confusion while also making things more secure.

This resulted in some breaking changes to permissions where the old system was not consistent. In most cases, the new system is more restrictive than the old system, so upon upgrade most users should not have more access than they previously had.

Some of these changes require additional permissions to do certain tasks. For users that tend to use built in User Roles, Octopus should continue to behave as it did before and no action is required.

Customers with complex permission configurations may want to pay careful attention to the release notes, as there may be action required after upgrade. While most of these changes affect edge cases that normal users won’t encounter, we recommend testing your permissions after upgrade to ensure they behave as you intend.

In general *Edit and *Delete permissions, now strictly requires the corresponding *View permission.

For example: AccountDelete now also requires AccountView MachinePolicyEdit now also requires MachinePolicyView And so on

Accounts

Retrieving accounts by ID is more restrictive now (to be consistent with the Index endpoint). It used to allow you to see documents with partial scoping (eg. no tenants) when your permissions were scoped, which is no longer the case. Getting the usage of accounts may require ProjectView

Certificates

Retrieving certificates by ID is more restrictive now (to be consistent with the Index endpoint). It used to allow you to see documents with partial scoping (eg. no tenants) when your permissions were scoped, which is no longer the case. Getting the usage of certificates may require ProjectView Viewing the public Octopus Server certificate no longer requires the MachineEdit permission. It is accessible by any authenticated user.

Action Templates

Search and logo retrieval requires ActionTemplateView Get usages of the action template requires ProjectView Updating deployment actions will skip actions that are inaccessible rather than failing Updating deployment actions additionally requires the ProjectView permission

Artifacts

Users with could not view/edit or create a completely unscoped artifact if their permissions were scoped, but now they can.

Audit

AuditView permission has been removed because it is no longer applicable, as you always needed EventView to actually see events via the Audit screen. There is no migration required for this, e.g. if you had AuditView without EventView previously, then you could not see any events anyway.

Cloud Template

The cloud template endpoint no longer requires the ProcessEdit permission. It is accessible by any authenticated user.

Deployment

Creating a deployment additionally requires ReleaseView, ProcessView, ProjectView, EnvironmentView, DeploymentView Modifying a deployment additionally requires EnvironmentView Tenanted deployments additionally require TenantView

Deployment Process

Getting a template requires ReleaseView Getting a list of Deployment processes now requires ProcessView

Events

Events that are scoped to multiple of the same type of document, and your EventView permission are scoped to the same documents then you can now see that event. You can see events that partially match your permissions scopes, instead of needing to match all of your permission scopes.

Feeds

Downloading packages or viewing the delta signature for the built in feed additionally requires the FeedView permission Searching for packages in the built in release feed requires ReleaseView and ProjectView. Modifying configuration for the built in feed now requires the BuiltInFeedAdminister instead of the ConfigureServer permission.

Interruptions

InterruptionViewSubmitResponsible is the only permission required to take responsibility and submit and interruption when that interruption has assigned responsible teams. To view an assigned interruption you may require UserView

Library Variable Sets

LibraryVariableSetView is now consistently checked in all scenarios where a variable set is accessed.

Lifecycles

Lifecycles can be created or edited only when the user has EnvironmentView access to all environments used by that lifecycle EnvironmentView is required to preview a lifecycle ‘ProcessView’ and ‘ProjectView’ are required to view projects connected to a lifecycle The lifecycle progression API now requires ProcessView, DeploymentView, TenantView, EnvironmentView and LifecycleView

Projects & Project Groups

Creating a project group and adding a project no longer requires ProcessView

Packages

When replacing an existing package, the BuiltInFeedPush permission check will take into account the project scopes applied to that permission You can no longer get the delta signature of a package scoped to a project, while your BuiltInFeedDownload permission was scoped to a different project

Releases

Editing a release requires ProcessView and ProjectView Updating release variables requires ProjectView Viewing a release requires ProjectView Getting a release template requires ProcessView and LifecycleView Getting the release progression requires ProcessView and LifecycleView

Server Nodes

Octopus Server Nodes GET endpoints are accessible to authenticated users - they don’t require administrator access. Any modifications still required administrator access.

Tasks

Cancelling a task requires TaskView, and any permissions that would be required to create that type of task (for example, EnvironmentView or MachineEdit for AdHoc Script tasks) Re-running a task requires the same permissions as creating that task. You can now always view the raw task log if you have TaskView for that task and also TaskViewLog. Modifying a task’s state when that task is not a Deployment task now requires TaskEdit scoped to that task, instead of requiring unscoped TaskEdit

Tenants

Getting tenant variables requires ProjectView Getting missing variables for tenants requires LibraryVariableSetView Updating the sort order for tag sets requires TagSetEdit instead of TenantEdit

Users

Getting a list of users will always return at least one result (yourself), even if you lack the UserView permission