Force Package Download Is Not Respected When Using A Lifecycle Where The First Environment Is Set To Deploy Automatically.

by ADMIN 123 views

Introduction

In this article, we will discuss a known issue in Octopus Deploy where the Force Package Download setting is not respected when using a lifecycle where the first environment is set to deploy automatically. This issue affects versions 2024.2.9396 and 2024.4.7205 of Octopus Deploy.

Severity

This issue is not blocking for customers, as they can manually re-run the deployment to force the package re-download. However, it is still essential to be aware of this issue to ensure smooth deployment processes.

Version

The affected versions of Octopus Deploy are 2024.2.9396 and 2024.4.7205.

Latest Version

There is no latest version available for this issue.

What Happened?

When a lifecycle is set to automatically deploy to an environment when a release is created, it does not respect either a Force Package = true variable (Octopus.Deployment.ForcePackageDownload) or a re-download package from feed deployment setting. However, if the same release is deployed manually, it will respect the Force Package Download setting.

Deployment Setting

The deployment setting is configured as follows:

Image

Lifecycle

The lifecycle is configured as follows:

Image

Release Deploy from a Creation (Automatically Created from the Lifecycle Rules)

The release is deployed automatically from the creation of the lifecycle rules:

Image

The Same Release Deployed Manually to the Same Environment (not using the Lifecycle Rules)

The same release is deployed manually to the same environment, not using the lifecycle rules:

Image

Image

Reproduction

To reproduce this issue, follow these steps:

  1. Create a lifecycle with at least two environments, set the first environment to 'Deploy automatically to this environment as soon as the release enters this phase.'
  2. Create a project with a Run a Script step, have a referenced package in there. (You can run a basic 'Write-Host' command for the script).
  3. Ensure the deployment settings are changed to use 'Force Package Download - Re-download packages from feed'
  4. Have the default channel for that project set to use the lifecycle we created in Step 1.
  5. Create a release, see it automatically deploy to the first environment but not use the force download variable (it uses the cache).
  6. Redeploy that release to the same environment manually, see it force the package download not use the cache.
  7. Create a new release (ensure you are using the exact same package and version as in the initial release creation) and see it automatically deploy to the first environment but see it use the cache and not force the package download. Since the same package is definitely on that target now, it will have it in the cache, but it should force the download.

Error and Stacktrace

There is no error or stacktrace associated with this issue.

More Information

For more information, please refer to the initial ticket (internal) - https://octopus.zendesk.com/agent/tickets/227950 and RnD (internal) -

Workaround

To work around this issue, manually re-deploy the release to the environment to force the package download from the feed.

Conclusion

Q: What is the issue with Force Package Download when using a lifecycle?

A: The issue is that when a lifecycle is set to automatically deploy to an environment when a release is created, it does not respect either a Force Package = true variable (Octopus.Deployment.ForcePackageDownload) or a re-download package from feed deployment setting.

Q: Why is this issue not blocking for customers?

A: This issue is not blocking for customers because they can manually re-run the deployment to force the package re-download.

Q: Which versions of Octopus Deploy are affected by this issue?

A: The affected versions of Octopus Deploy are 2024.2.9396 and 2024.4.7205.

Q: What is the workaround for this issue?

A: The workaround for this issue is to manually re-deploy the release to the environment to force the package download from the feed.

Q: Why does the issue only occur when using a lifecycle?

A: The issue only occurs when using a lifecycle because the lifecycle is set to automatically deploy to an environment when a release is created, which bypasses the Force Package Download setting.

Q: Can I reproduce this issue?

A: Yes, you can reproduce this issue by following the steps outlined in the "Reproduction" section of the original article.

Q: What are the steps to reproduce this issue?

A: The steps to reproduce this issue are:

  1. Create a lifecycle with at least two environments, set the first environment to 'Deploy automatically to this environment as soon as the release enters this phase.'
  2. Create a project with a Run a Script step, have a referenced package in there. (You can run a basic 'Write-Host' command for the script).
  3. Ensure the deployment settings are changed to use 'Force Package Download - Re-download packages from feed'
  4. Have the default channel for that project set to use the lifecycle we created in Step 1.
  5. Create a release, see it automatically deploy to the first environment but not use the force download variable (it uses the cache).
  6. Redeploy that release to the same environment manually, see it force the package download not use the cache.
  7. Create a new release (ensure you are using the exact same package and version as in the initial release creation) and see it automatically deploy to the first environment but see it use the cache and not force the package download. Since the same package is definitely on that target now, it will have it in the cache, but it should force the download.

Q: Is there an error or stacktrace associated with this issue?

A: No, there is no error or stacktrace associated with this issue.

Q: Where can I find more information about this issue?

A: For more information, please refer to the initial ticket (internal) - https://octopus.zendesk.com/agent/tickets/227950 and RnD (internal) -

Q: Is this issue fixed in a later version of Octopus Deploy?

A: No, this issue is not fixed in a later version of Octopus Deploy. However, the workaround of manually re-deploying the release to the environment to force the package download from the feed can be used to resolve the issue.