Add project dashboard page #2684
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
|
|
| title: Project dashboard | ||
| icon: fa-solid fa-shapes | ||
| description: Understanding the different project dashboard views. | ||
| position: 20 |
There was a problem hiding this comment.
This looks like old frontmatter... we don't use position, hideInThisSection, or hideInThisSectionHeader
You can use navOrder instead of position and navMenu: false if you want to hide it from navigation.
|
I've sent this PR through the deployment channel to staging so you can check whether it looks how you want! http://octopus-docs-staging.s3-website-us-east-1.amazonaws.com/docs/ |
| #### Packages | ||
|
|
||
| Packages that are transferred during the deployment are managed based on free disk space. For each deployment, prior to acquiring the package, the free disk space is checked and if less than 20% it will delete the “least used” package(s) from the Tentacle file store location. Packages that gets removed will be reacquired if needed for another deployment. | ||
| The disk space calculation for both targets and workers looks at the entire disk, however Octopus only cleans up in the file store. | ||
|
|
||
| ### Built-in repository \{#built-in-repo-whats-deleted} | ||
|
|
||
| A retention policy can be applied to packages in the built-in Octopus package repository. By default, the policy is set to keep all packages indefinitely. This policy is *separate* from the [release retention policy](#releases-whats-deleted) described above. | ||
| A retention policy can be applied to packages in the built-in Octopus package repository. By default, the policy is set to keep all packages indefinitely. This policy is _separate_ from the [release retention policy](#releases-whats-deleted) described above. |
There was a problem hiding this comment.
Suggested change
| A retention policy can be applied to packages in the built-in Octopus package repository. By default, the policy is set to keep all packages indefinitely. This policy is _separate_ from the [release retention policy](#releases-whats-deleted) described above. | |
| A retention policy can be applied to packages in the built-in Octopus package repository. By default, the policy is set to keep all packages indefinitely. This policy is *separate* from the [release retention policy](#releases-whats-deleted) described above. |
Our markdown lint style has asterisks for emphasis:
"emphasis": { "style": "asterisk" },| ::: | ||
|
|
||
| When a package retention policy is applied, Octopus will delete packages that meet *both* of the following criteria: | ||
| When a package retention policy is applied, Octopus will delete packages that meet _both_ of the following criteria: |
There was a problem hiding this comment.
Suggested change
| When a package retention policy is applied, Octopus will delete packages that meet _both_ of the following criteria: | |
| When a package retention policy is applied, Octopus will delete packages that meet *both* of the following criteria: |
| @@ -108,22 +111,23 @@ If you have a release retention policy for a project that has a final phase of k | |||
| In this section we walk through what's deleted for an example project when the retention policy task runs. Consider a project that has the following lifecycle defined: | |||
|
|
|||
| :::figure | |||
|  | |||
|  | |||
There was a problem hiding this comment.
Suggested change
|  | |
|  |
These width attributes are an artifact from the old docsync project. They have no effect in new docs.
| @@ -164,16 +168,16 @@ Undeployed releases will simply keep the number we have selected and no more. Wh | |||
| Under **Deploy ➜ Lifecycles** you select the Lifecycle you want to define or edit your retention policy for: | |||
|
|
|||
| :::figure | |||
|  | |||
|  | |||
There was a problem hiding this comment.
Suggested change
|  | |
|  |
| ::: | ||
|
|
||
| Each phase will inherit the retention policy from the above phase, but this is something you can change by expanding the Retention Policy panel. | ||
|
|
||
| :::figure | ||
|  | ||
|  |
There was a problem hiding this comment.
Suggested change
|  | |
|  |
| ::: | ||
|
|
||
| *Releases* determines what is kept on the Octopus Server, and *Files on Tentacle* determines what files are kept on the Tentacle. | ||
| _Releases_ determines what is kept on the Octopus Server, and _Files on Tentacle_ determines what files are kept on the Tentacle. |
There was a problem hiding this comment.
Suggested change
| _Releases_ determines what is kept on the Octopus Server, and _Files on Tentacle_ determines what files are kept on the Tentacle. | |
| *Releases* determines what is kept on the Octopus Server, and *Files on Tentacle* determines what files are kept on the Tentacle. |
| @@ -203,18 +209,18 @@ Phases prioritize retention policies from the latest previous phase over the lif | |||
| You can find the built-in repository retention policy settings under **Deploy ➜ Packages**. | |||
|
|
|||
| :::figure | |||
|  | |||
|  | |||
There was a problem hiding this comment.
Suggested change
|  | |
|  |
| ::: | ||
|
|
||
| In Octopus Server, this can be set to keep packages forever, or for a set number of days. | ||
|
|
||
| <OctopusCloudStorageLimits /> | ||
|
|
||
| :::figure | ||
|  | ||
|  |
There was a problem hiding this comment.
Suggested change
|  | |
|  |
| ::: | ||
|
|
||
| Choosing *A limited time* will allow you to select the number of days to keep a package in the repository. The default value is 30, but you can choose something shorter or longer based on your needs. | ||
| Choosing _A limited time_ will allow you to select the number of days to keep a package in the repository. The default value is 30, but you can choose something shorter or longer based on your needs. |
There was a problem hiding this comment.
Suggested change
| Choosing _A limited time_ will allow you to select the number of days to keep a package in the repository. The default value is 30, but you can choose something shorter or longer based on your needs. | |
| Choosing *A limited time* will allow you to select the number of days to keep a package in the repository. The default value is 30, but you can choose something shorter or longer based on your needs. |
|
|
||
| ## Triggers {#triggers} | ||
|
|
||
| Triggers are per-project settings that execute an action in response to an event. For this example we will create an automatic deployment trigger so that machines associated with the **TradingWebServer** [target tag](/docs/infrastructure/deployment-targets/#target-roles) are automatically kept up to date with the latest releases for OctoFX. Triggers can be found by selecting the *Triggers* menu item on the project screen. | ||
| Triggers are per-project settings that execute an action in response to an event. For this example we will create an automatic deployment trigger so that machines associated with the **TradingWebServer** [target tag](/docs/infrastructure/deployment-targets/#target-roles) are automatically kept up to date with the latest releases for OctoFX. Triggers can be found by selecting the _Triggers_ menu item on the project screen. |
There was a problem hiding this comment.
Suggested change
| Triggers are per-project settings that execute an action in response to an event. For this example we will create an automatic deployment trigger so that machines associated with the **TradingWebServer** [target tag](/docs/infrastructure/deployment-targets/#target-roles) are automatically kept up to date with the latest releases for OctoFX. Triggers can be found by selecting the _Triggers_ menu item on the project screen. | |
| Triggers are per-project settings that execute an action in response to an event. For this example we will create an automatic deployment trigger so that machines associated with the **TradingWebServer** [target tag](/docs/infrastructure/deployment-targets/#target-roles) are automatically kept up to date with the latest releases for OctoFX. Triggers can be found by selecting the *Triggers* menu item on the project screen. |
|
|
||
| ## Creating an automatic deployment trigger {#create-automatic-deployment-trigger} | ||
|
|
||
| 1. Navigate to the project *Triggers* page. | ||
| 1. Navigate to the project _Triggers_ page. |
There was a problem hiding this comment.
Suggested change
| 1. Navigate to the project _Triggers_ page. | |
| 1. Navigate to the project *Triggers* page. |
| 2. Create a new trigger by selecting **Create trigger**: | ||
|
|
||
| :::figure | ||
|  | ||
| ::: | ||
|
|
||
| 3. Add events to the trigger. | ||
| - For **Octopus 3.6** and above, select the event group *"Machine becomes available for deployment"*. | ||
|
|
||
| - For **Octopus 3.6** and above, select the event group _"Machine becomes available for deployment"_. |
There was a problem hiding this comment.
Suggested change
| - For **Octopus 3.6** and above, select the event group _"Machine becomes available for deployment"_. | |
| - For **Octopus 3.6** and above, select the event group *"Machine becomes available for deployment"*. |
|
|
||
| :::figure | ||
|  | ||
| ::: | ||
|
|
||
| ## Overriding the release used for automatic deployments {#override-release-for-automatic-deployments} | ||
|
|
||
| Automatic deployments attempts to calculate the release to use for a project and environment (using the *current* and *successful* release that has been deployed, as shown in your Project Overview dashboard). In some cases the calculated release may not be the release that should be automatically deployed, or Octopus may not be able to find a deployment for an environment (maybe you have a release, but have not yet deployed it anywhere). It is possible to explicitly set the release that should be automatically deployed by overriding the automatic-deployment-release. Overrides can be configured using the [Octopus CLI](/docs/octopus-rest-api/octopus-cli/) or through [Octopus.Client](/docs/octopus-rest-api/octopus.client). Overrides define a release for a project when deploying to an environment (this can, for example, be useful for cloud-testing-automation when standing up new cloud infrastructure). For multi-tenanted deployments, overrides may be configured for each environment/tenant combination. | ||
| Automatic deployments attempts to calculate the release to use for a project and environment (using the _current_ and _successful_ release that has been deployed, as shown in your Project Overview dashboard). In some cases the calculated release may not be the release that should be automatically deployed, or Octopus may not be able to find a deployment for an environment (maybe you have a release, but have not yet deployed it anywhere). It is possible to explicitly set the release that should be automatically deployed by overriding the automatic-deployment-release. Overrides can be configured using the [Octopus CLI](/docs/octopus-rest-api/octopus-cli/) or through [Octopus.Client](/docs/octopus-rest-api/octopus.client). Overrides define a release for a project when deploying to an environment (this can, for example, be useful for cloud-testing-automation when standing up new cloud infrastructure). For multi-tenanted deployments, overrides may be configured for each environment/tenant combination. |
There was a problem hiding this comment.
Suggested change
| Automatic deployments attempts to calculate the release to use for a project and environment (using the _current_ and _successful_ release that has been deployed, as shown in your Project Overview dashboard). In some cases the calculated release may not be the release that should be automatically deployed, or Octopus may not be able to find a deployment for an environment (maybe you have a release, but have not yet deployed it anywhere). It is possible to explicitly set the release that should be automatically deployed by overriding the automatic-deployment-release. Overrides can be configured using the [Octopus CLI](/docs/octopus-rest-api/octopus-cli/) or through [Octopus.Client](/docs/octopus-rest-api/octopus.client). Overrides define a release for a project when deploying to an environment (this can, for example, be useful for cloud-testing-automation when standing up new cloud infrastructure). For multi-tenanted deployments, overrides may be configured for each environment/tenant combination. | |
| Automatic deployments attempts to calculate the release to use for a project and environment (using the *current* and *successful* release that has been deployed, as shown in your Project Overview dashboard). In some cases the calculated release may not be the release that should be automatically deployed, or Octopus may not be able to find a deployment for an environment (maybe you have a release, but have not yet deployed it anywhere). It is possible to explicitly set the release that should be automatically deployed by overriding the automatic-deployment-release. Overrides can be configured using the [Octopus CLI](/docs/octopus-rest-api/octopus-cli/) or through [Octopus.Client](/docs/octopus-rest-api/octopus.client). Overrides define a release for a project when deploying to an environment (this can, for example, be useful for cloud-testing-automation when standing up new cloud infrastructure). For multi-tenanted deployments, overrides may be configured for each environment/tenant combination. |
|
|
||
| ## Troubleshooting automatic deployments {#troubleshoot-automatic-deployments} | ||
|
|
||
| Octopus will attempt to automatically deploy the current releases for the environments that are appropriate for a machine. The current release is the one that was most recently *successfully* deployed as shown on the project dashboard. If a release is deployed and it fails, the previous successful release will continue to be automatically deployed. Octopus will not attempt automatic deployments for a project/environment/tenant while a release is being deployed to that project/environment/tenant. Once the deployment finishes, Octopus will deploy to any machines that require the deployment. | ||
| Octopus will attempt to automatically deploy the current releases for the environments that are appropriate for a machine. The current release is the one that was most recently _successfully_ deployed as shown on the [project dashboard](/docs/projects/project-dashboard). If a release is deployed and it fails, the previous successful release will continue to be automatically deployed. Octopus will not attempt automatic deployments for a project/environment/tenant while a release is being deployed to that project/environment/tenant. Once the deployment finishes, Octopus will deploy to any machines that require the deployment. |
There was a problem hiding this comment.
Suggested change
| Octopus will attempt to automatically deploy the current releases for the environments that are appropriate for a machine. The current release is the one that was most recently _successfully_ deployed as shown on the [project dashboard](/docs/projects/project-dashboard). If a release is deployed and it fails, the previous successful release will continue to be automatically deployed. Octopus will not attempt automatic deployments for a project/environment/tenant while a release is being deployed to that project/environment/tenant. Once the deployment finishes, Octopus will deploy to any machines that require the deployment. | |
| Octopus will attempt to automatically deploy the current releases for the environments that are appropriate for a machine. The current release is the one that was most recently *successfully* deployed as shown on the [project dashboard](/docs/projects/project-dashboard). If a release is deployed and it fails, the previous successful release will continue to be automatically deployed. Octopus will not attempt automatic deployments for a project/environment/tenant while a release is being deployed to that project/environment/tenant. Once the deployment finishes, Octopus will deploy to any machines that require the deployment. |
| @@ -74,8 +74,8 @@ Deployment target triggers let you configure unattended deployment behavior that | |||
|
|
|||
| When a deployment target trigger fires, the following rules are applied: | |||
|
|
|||
| - By default, Octopus will re-run the *currently successful* deployment for the project/environment/tenant combination. You can override this behavior by configuring an [auto deploy override](/docs/octopus-rest-api/octopus-cli/create-autodeployoverride). Note, if multiple identical deployment targets all become available within the same 30 second polling window, they will all be included in the same automatic deployment. This could happen if you scale your web farm up by four nodes, and all four nodes finish provisioning within the same time window. However, this kind of behavior should not be expected or relied on (one or more of the targets might fall outside the 30 second window). | |||
| - The steps that were run for the *currently successful* deployment will be run for the deployment targets that triggered the deployment. This includes [manual intervention](/docs/projects/built-in-step-templates/manual-intervention-and-approvals/) and [guided failure](/docs/releases/guided-failures) steps. Note, if you skip steps in a manual deployment, they will be skipped in the subsequent automatic deployment. If you need to run a deployment and skip some steps, there are two ways you can reset the skipped steps: | |||
| - By default, Octopus will re-run the _currently successful_ deployment for the project/environment/tenant combination. You can override this behavior by configuring an [auto deploy override](/docs/octopus-rest-api/octopus-cli/create-autodeployoverride). Note, if multiple identical deployment targets all become available within the same 30 second polling window, they will all be included in the same automatic deployment. This could happen if you scale your web farm up by four nodes, and all four nodes finish provisioning within the same time window. However, this kind of behavior should not be expected or relied on (one or more of the targets might fall outside the 30 second window). | |||
There was a problem hiding this comment.
Suggested change
| - By default, Octopus will re-run the _currently successful_ deployment for the project/environment/tenant combination. You can override this behavior by configuring an [auto deploy override](/docs/octopus-rest-api/octopus-cli/create-autodeployoverride). Note, if multiple identical deployment targets all become available within the same 30 second polling window, they will all be included in the same automatic deployment. This could happen if you scale your web farm up by four nodes, and all four nodes finish provisioning within the same time window. However, this kind of behavior should not be expected or relied on (one or more of the targets might fall outside the 30 second window). | |
| - By default, Octopus will re-run the *currently successful* deployment for the project/environment/tenant combination. You can override this behavior by configuring an [auto deploy override](/docs/octopus-rest-api/octopus-cli/create-autodeployoverride). Note, if multiple identical deployment targets all become available within the same 30 second polling window, they will all be included in the same automatic deployment. This could happen if you scale your web farm up by four nodes, and all four nodes finish provisioning within the same time window. However, this kind of behavior should not be expected or relied on (one or more of the targets might fall outside the 30 second window). |
| - By default, Octopus will re-run the *currently successful* deployment for the project/environment/tenant combination. You can override this behavior by configuring an [auto deploy override](/docs/octopus-rest-api/octopus-cli/create-autodeployoverride). Note, if multiple identical deployment targets all become available within the same 30 second polling window, they will all be included in the same automatic deployment. This could happen if you scale your web farm up by four nodes, and all four nodes finish provisioning within the same time window. However, this kind of behavior should not be expected or relied on (one or more of the targets might fall outside the 30 second window). | ||
| - The steps that were run for the *currently successful* deployment will be run for the deployment targets that triggered the deployment. This includes [manual intervention](/docs/projects/built-in-step-templates/manual-intervention-and-approvals/) and [guided failure](/docs/releases/guided-failures) steps. Note, if you skip steps in a manual deployment, they will be skipped in the subsequent automatic deployment. If you need to run a deployment and skip some steps, there are two ways you can reset the skipped steps: | ||
| - By default, Octopus will re-run the _currently successful_ deployment for the project/environment/tenant combination. You can override this behavior by configuring an [auto deploy override](/docs/octopus-rest-api/octopus-cli/create-autodeployoverride). Note, if multiple identical deployment targets all become available within the same 30 second polling window, they will all be included in the same automatic deployment. This could happen if you scale your web farm up by four nodes, and all four nodes finish provisioning within the same time window. However, this kind of behavior should not be expected or relied on (one or more of the targets might fall outside the 30 second window). | ||
| - The steps that were run for the _currently successful_ deployment will be run for the deployment targets that triggered the deployment. This includes [manual intervention](/docs/projects/built-in-step-templates/manual-intervention-and-approvals/) and [guided failure](/docs/releases/guided-failures) steps. Note, if you skip steps in a manual deployment, they will be skipped in the subsequent automatic deployment. If you need to run a deployment and skip some steps, there are two ways you can reset the skipped steps: |
There was a problem hiding this comment.
Suggested change
| - The steps that were run for the _currently successful_ deployment will be run for the deployment targets that triggered the deployment. This includes [manual intervention](/docs/projects/built-in-step-templates/manual-intervention-and-approvals/) and [guided failure](/docs/releases/guided-failures) steps. Note, if you skip steps in a manual deployment, they will be skipped in the subsequent automatic deployment. If you need to run a deployment and skip some steps, there are two ways you can reset the skipped steps: | |
| - The steps that were run for the *currently successful* deployment will be run for the deployment targets that triggered the deployment. This includes [manual intervention](/docs/projects/built-in-step-templates/manual-intervention-and-approvals/) and [guided failure](/docs/releases/guided-failures) steps. Note, if you skip steps in a manual deployment, they will be skipped in the subsequent automatic deployment. If you need to run a deployment and skip some steps, there are two ways you can reset the skipped steps: |
| @@ -114,7 +114,7 @@ There are a number of reasons why automatic deployments may not work the way you | |||
|
|
|||
| ### Is the dashboard green? | |||
|
|
|||
| Octopus will attempt to automatically deploy the current releases for the environments that are appropriate for a machine. The current release is the one that was most recently *successfully* deployed as shown on the project dashboard. | |||
| Octopus will attempt to automatically deploy the current releases for the environments that are appropriate for a machine. The current release is the one that was most recently _successfully_ deployed as shown on the [project dashboard](/docs/projects/project-dashboard). | |||
There was a problem hiding this comment.
Suggested change
| Octopus will attempt to automatically deploy the current releases for the environments that are appropriate for a machine. The current release is the one that was most recently _successfully_ deployed as shown on the [project dashboard](/docs/projects/project-dashboard). | |
| Octopus will attempt to automatically deploy the current releases for the environments that are appropriate for a machine. The current release is the one that was most recently *successfully* deployed as shown on the [project dashboard](/docs/projects/project-dashboard). |
steve-fenton-octopus
requested changes
Apr 25, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Add project dashboard page which explains how releases are selected for display on the various views of the project dashboard.
After Change
The project dashboard page was added.
It is also linked in a number of places in the docs, especially when a user may want to understand which releases will be displayed on the dashboard.